微服务架构简介（4）— 是不是看起来与 SOA 很像

1.6 是不是看起来与 SOA 很像

微服务和SOA像吗？答案只有一个：绝对像！那么微服务和SOA有什么区别吗？答案也是只有一个：绝对有！微服务架构确实受到了SOA的一些启发。微服务架构看起来与SOA颇为相似，但是下面我们要提到的这些关键不同点让微服务优于SOA。在SOA中，我们也需要把问题拆分为不同的服务，一种典型的通信方式是各个服务之间使用SOAP协议。在服务总线上，连接了很多消费者和许多服务。消费者可以通过向企业消息总线（Enterprise Service Bus，ESB）发消息的方式来调用任何服务。与在微服务中的情形类似，SOA里面这些不同的服务也可以分别使用不同的编程语言来实现。SOA并不强调这些服务的边界上下文，在微服务中虽然不是十分严格，但是一般会按照单一职责原则给出一些服务的边界上下文，也就是服务的边界。SOA架构中的数据库一般是各个服务所共享的，但是在微服务中每个服务有其独自享有的

数据库，其他服务无法直接接触到。SOA很重要的一个设计原则是“尽可能多地共享”，这也是为什么SOA的数据库通常设计成多个服务共享的根本原因。这种共享会增加服务之间的耦合，也是与微服务的理念相悖的。微服务中的原则是“尽可能少地共享”，正是因为这个根本性的不同，导致了两种架构表现出完全不同的设计思路和实现方式。

SOA中的通信层是ESB中间件，会演变成单点故障。如果ESB出现了故障，则没有一个服务能正常工作，既无法调用数据，也无法与其他服务进行通信。微服务中各个服务基于孤立原则设计，可以有效规避这种单点故障。微服务典型的通信方式是REST风格的API，这种方式在极大程度上去除了ESB这种重量级的作为通信层的中间件。微服务还去除了效。图1-3是一个典型的SOA应用的示意图。

上面提到的这些SOA早期的问题现在很多都有办法在架构内部解决和优化，但是不是所有的问题都能解决。SOA是一个非常广义的概念，我们可以把微服务视为SOA的一个子集，一个特例。这个特例通过定义一些更细致的规则实现了更好的面向服务设计。有一句名言是这样描述微服务的：微服务是SOA的一种更好的实现。

与单体架构相比，微服务架构的最主要优势在于其上线速度快。不仅初创公司在使用微服务，有很多大公司也在采用，很多使用者选用微服务就是因为微服务可以大大缩短产品上市时间（Time to Market，TTM）。市场上的需求始终是动态并随时间变化着的，谁能更快地发布产品谁就能率先抢占市场，因此产品上市时间显得尤为关键。好的产品会根据市场的反应来调整一些业务需求，微服务架构完美的适用于这种频繁修改需求的场景。微服务架构能快速完成产品的开发、测试到上线的整个流程。当今的市场瞬息万变，竞争也十分激烈，用户的反馈声音也愈加重要。产品的基本迭代周期是这样的：研发、测试、上线、收集市场上的用户反馈、针对反馈的后续开发、再次测试、再次上线。如果哪一个产品能比竞争者在更短的时间内交付新功能，或者根据市场反馈进行相应的改进升级，那么该产品无疑会迅速抢占市场，占据主动。在单体架SOA中的服务契约部分，由于在SOA中并没有边界上下文的概念，某个服务可以直接修改其他数据模型，为了能这么做就经常需要把数据模型共享出去。这个数据模型可能是个有层级的复杂数据结构。一旦这个共享中的数据结构发生了一点变化，所有牵连到的服务都要修改接口才行，最后还需要把整个应用程序重新部署一遍才能生构中做到快速发布上线是很难的，哪怕是一个很小的功能上线也需要牵连到整个应用程序的测试和部署。

1.7 将业务领域划分为微服务组件

要设计健壮的微服务架构，首先标识出业务领域，然后围绕各个领域定义该领域应具有的功能，最后再围绕这些功能和领域进行微服务的划分和开发。业务领域的划分可以使用领域驱动设计（Domain-Driven Design，DDD）的方式来进行。领域驱动设计是一种解决复杂需求的软件开发方式，使用领域驱动设计可以将具体实现和演化模型很好地联系起来。DDD这个词是2004年引入的，一并引入的还有这样一些关键词：建模、边界上下文、实体、代码库和通用语言等。DDD和微服务的理念很契合，因此DDD也随着微服务的流行而逐渐广为人知。DDD

的理念是尝试理解问题的领域，然后围绕领域进行建模。DDD建议使用者基于真实的用户案例进行建模。建模过程主要是围绕领域，定义一组概念、功能和边界上下文。DDD有这样一些基本概念。

通用语言：指的是所有的利益相关者（业务部门、运营人员、开发人员）应该使用相同的语言（术语）来描述问题，这种语言不应该太偏向技术方面，而应该更加贴合业务方的模型。该通用语言应该和领域的边界上下文有关。

边界上下文：边界上下文的主要目的是用来定义模型的范围和清晰的上下文边界，然后尽最大可能保持模型统一。最终定义出的模型应该是各方面达成一致的，而且是限定在清晰定义了的边界内。每一个边界上下文都应该是与其他的上下文相互独立的，边界上下文定义了不同领域所分担的职责。某些业务可以设计多个领域，如货运、库存、销售、市场等。每个领域有其自己的功能。每个实体或业务组件都应该只存在于其自己的边界上下文中。DDD的概念可以帮助我们识别出来这些领域和他们的分离点。整个DDD的概念都符合微服务的原则。围绕模型进行思考，按照边界上下文对模型进行封装，这些上下文就清楚地定义了模型的边界。微服务是彼此隔离的，因此对于微服务的职责和界进行合理的划分显得非常有必要。如果采用DDD，我们可以通过边界上下文将一个大的问题分解为一些小的问题，进而可以让我们更好地理解和定义微服务。如果职责没有划分清楚，就会在微服务之间产生职责泄露，然后系统会在这些边界不清楚的地方变成“大泥球”。

DDD可以帮助我们理解和定义边界上下文。关于领域驱动设计有一本不错的书可以推荐大家阅读，叫Implementing Domain-Driven Design

①，作者是Vaughn Vernon。通过这本书读者可以大大加深对领域驱动设计的理解。

围绕业务功能组织微服务组件

微服务可以给组织的交付速度赋能。使用微服务的组织可以更快地响应市场变化，可以极大提高生产力、交付能力以及项目交付速度。然而选择微服务的组织中，一个很大的挑战是组织结构同样需要围绕微服务架构进行一些调整。可以这么说，微服务并不适用于每个组织。实现微服务也在一定程度上会动摇一些组织结构。

业务功能可以定义为用于特定业务目的的一个独立业务单元。组织中的各个层级和领域可能都会定义业务功能。从管理层到运营部门再到销售和技术人员，不同部门可能会有一些不同的业务功能的定义。因此我们要识别适合的业务功能的粒度，然后围绕这些业务功能安排微服务。

业务功能和微服务从定义上看像是同一个东西，但是它们是不同的。例如，搞一个促销活动可能是市场部门的一个业务功能，围绕这个功能我们需要一个电子邮件发送服务、一个促销链接生成服务和一个数据收集服务等。这是一个两步的过程：

（1）识别正确的业务功能；

（2）围绕该业务功能定义微服务。

这两步缺一不可，而且要划分好粒度，只有这么做才能设计出好的微服务架构。另外一个重要的因素是沟通交流。沟通在任何形式的业务中都是必不可少的。团队与团队之间需要沟通，组织与组织之间也需要沟通，收集终端用户的持续反馈同样也需要沟通，组织内部各个不同的管理层之间需要沟通，甚至组织内部软件系统的不同组件之间如何协同工作都需要沟通。有这样一条定律将软件系统的沟通方式和组织结构的沟通方式联系了起来，它就是康威定律：设计系统的组织，其产生的设计的结构等同于组织之内、组织之间的沟通结构。

康威定律对于很多初次接触的人来说有些难以置信。一些知名院校（如麻省理工学院和哈佛大学）认真研究过这个问题。他们在这个定律上做了一些研究，他们比较了不同组织结构中研发出来的代码，最后发现真的是合康威定律的。他们采集到的代码中，90%都是完美符合康威定律的。为了理解这一点，我们以单体架构举一个例子：如果你有一个庞大的开发团队，所有的开发成员都在同一个地方协同办公，那么你最后做出来的肯定就是一个单体应用；如果都是一些小的团队，团队内大家在一起协同开发，但是团队与团队之间是不需要待在一起的，那么最后做出来的东西肯定是分布式的或者多模块的，就像很多开源项目一样。开源项目一般都是分布式的和多模块架构的，因为它们通常都是由很多小团队（某些团队小到只有1个人）而不是一个很多人的大团队完成的，这些小团队之间不是一直在协作沟通的。康威定律虽然没有提到任何与微服务相关的东西，但是康威定律告诉了我们团队结构或组织结构将如何影响软件应用的设计。

根据康威定律，软件应用的架构最后会是组织关系的一个副本，组织结构很可能会影响应用架构，团队所处的工作地点和团队沟通方式也会影响应用架构，软件应用的架构最终会与组织结构一致。反向亦是如此，例如一个组织里面有5个开发团队，每个团队有4个开发人员，某一天我们遇到一个棘手的问题，不好拆分到某一个具体的服务里面交由某一个团队单独完成。这个时候可能不得不把两个团队重新组合成一个团队。这就是一个软件架构反向改变组织架构的例子。

事实情况是，每个公司都有其自身的规范、业务功能和目标以及团队结构和沟通方式。在实施微服务的过程中，或多或少会改变这些既有的组织结构。所以如果想做好微服务的话，首先需要做的功课是了解清楚组织里面当前的组织结构和沟通方式。

原文网址：https://www.epubit.com/book/detail/33225

内容来源：异步社区；版权属【人民邮电出版社 异步社区】所有，转载已获得授权；未经授权，不得以任何方式复制和传播本书内容，如需转载请联系异步社区。