标签
Microservices，Architecture，Anti-pattern
位置
2018年11月第19期技术雷达，技术象限，建议暂缓。
目标受众
系统架构师，技术管理者，开发设计人员
关注问题
构建微服务架构首当其冲要解决的问题，就是业务服务如何划分的问题。我们发现很多组织在技术快速发展的今天，仍然会重蹈过去的覆辙，对于服务按照以前的多层架构的分层方式进行划分。这样的架构各个层次之间并未真正解耦，不利于团队协作和架构治理。不但没有尝到微服务所带来的独立交付业务价值的甜头，还要承受微服务所引入的的运维复杂度。
解决方案
按照业务能力（business capabilities）而非技术能力来划分团队和服务。
解读
对于N年前的多层架构来说，层往往是按照技术能力来划分的。以最典型的三层架构为例，包含用户界面层、业务逻辑层和数据访问层，分别由擅长前端、后台和数据库的团队来维护。每一层可以部署在不同的服务器上，构成了分布式系统的雏形。
但这样的架构很快就会出现问题。因为用户访问的是业务功能，不是上述某一个特定的层，所以用户的每一次访问都会贯穿这三层服务。任何一层出现问题，都会导致这次访问失败。而每当新的功能需要交付时，都必然要修改和重新部署所有的层次。
我们常用切蛋糕来举例子。分层架构就像是横切蛋糕，切下来的每一块都只是那一层的原材料，可能是奶油，可能是水果，也可能是慕斯。但每一块都不是完整的蛋糕（业务功能）。只有纵切蛋糕，奶油水果慕斯蛋糕一应俱全，才是用户真正想要的东西。所以我们都是纵切，切出来的每一块蛋糕都是可以分给别人吃的（独立交付的单元）。
微服务架构正是基于此诞生的。它打破了传统多层架构的束缚，以业务能力而非技术能力来划分服务和组件。比如在电商系统里常见的微服务可能包括商品服务、订单服务、支付服务等，而在传统多层架构下这些只是业务逻辑层和数据访问层的一部分内容。微服务和传统多层架构对于服务的划分，是正交的。
随着近年来的飞速发展，微服务已经逐渐成为主流架构。但无论技术如何快速变化，一些企业仍然想方设法地重新实现过去的反模式。分层式微服务架构（Layered Microservices Architecture）就是这样一种反模式。它打着微服务的旗号，但仍然按照技术能力来划分服务。比如用户体验API、进程API或系统API等。这导致任何有价值的业务变更，都需要缓慢而昂贵的多团队合作。微服务独立演进、独立交付、快速响应变化的好处一个也体会不到。
之所以陷入这样的误区，还是康威定律在背后起着作用。因为组织仍然按照技术能力而不是业务能力来划分团队，那么步入以技术能力来划分服务的歧途也就在所难免了。
传统的SOA由于没有重视康威定律的作用，在设计时很容易导致这种分层式服务。网上有很多讨论SOA和微服务区别的文章，实际上指的就是这种分“基于技术分层的服务化”与“按照业务边界划分的微服务”之间的区别。这样的解读使得SOA蒙受了不白之冤，因为它对于服务的拆分并没有这样的限制。我们以后可以使用“分层式微服务”这个术语来特指这种类型的设计。
在最新的2018年第19期ThoughtWorks技术雷达中，分层式微服务架构首次入选，并进入“暂缓”行列。我们强烈建议组织评估这种分层方式带来的影响，我们更推荐根据业务能力来划分服务和团队。
注意，这里的分层（layered）特指按照技术能力来划分微服务，会导致教条式的逐层调用。它并不代表按照业务划分的微服务之间，根据不同服务的职责所划分的层次。比如，有些服务负责具体的业务能力，有些服务则会将不同业务服务组合起来，并提供一个对调用端更加友好的接口，我们常常称之为Composer或Orchestrator。这样的“分层”属于categorized，不是layered。
