关于微服务是什么，面向服务的体系结构（SOA）又是什么，两者之间有何关联真是众说纷纭、困惑颇多。很多人都加入了这场讨论，从ThoughtWorks的Martin Fowler到Cap Gemini的Steve Jones全都参与了进来。

微服务是什么？

微服务是一种架构设计模式。在微服务架构中，业务逻辑被拆分成一系列小而松散耦合的分布式组件，共同构成了较大的应用。每个组件都被称为微服务，而每个微服务都在整体架构中执行着单独的任务，或负责单独的功能。每个微服务可能会被一个或多个其他微服务调用，以执行较大应用需要完成的具体任务；系统还为任务执行——比如搜索或显示图片任务，或者其他可能需要多次执行的任务提供了统一的解决处理方式，并限制应用内不同地方生成或维护相同功能的多个版本。

使用微服务架构还提供这样一种机制：增加新加入开发者的生产效率，并减少新功能的推广时长。每个微服务的代码库与相关工具集都很有限；开发者无需再去了解庞大而复杂的系统，只需理解自己所做的那部分微服务相关子集，便能贡献生产力。由于无需考虑应用的现有部分使用了什么语言或工具集，或者较大应用的其他开发者是否了解这些语言和工具，只需使用当前任务最趁手的工具，因此微服务开发起来非常迅速。

为了充分利用速度优势，让小团队开发成为可能，团队需要自主权；他们必须能迅速作出决定，避免过度监管。要想支持这一点，工作团队应当包括所有相关人员，从产品经理到发布运行人员。由于微服务组件是松散耦合并通过API通讯的，各方在大多决定时拥有高度自主权并不会影响应用的整体功能。只要微服务能发布API，并能用这些API执行所需的功能，整体系统就能运作良好。

由于在一个微服务架构中有许多独立的组件，在弹性网络（比如公共或私有云）上使用现代化的DevOps对于确保整体系统在大多数情况下正常运转就显得尤为重要。特别是像与额外实例的自动部署相关联的健康与负载自动监控（为了尽可能减少未充分利用的实例）这样的东西在很多情况下就变得至关重要。

SOA是什么？

服务导向式架构（SOA）是集成多个较大组件（一般是应用）的一种机制，它们将整体构成一个彼此协作的套件。一般来说，每个组件会从始至终执行一块完整的业务逻辑，通常包括完成整体大action所需的各种具体任务与功能。组件一般都是松耦合的，但这并非SOA架构模式的要求。

尽管没有严格要求，SOA一般使用某种集中式管理，比如审查委员会、主架构师或架构委员会来严格定义每个系统组件应当做什么，如何执行。相同类型的功能可能会按需在多个组件中分别定义与记录，而每个组件所使用的语言与工具集有可能是集中确定与统一的，也可能不是。SOA可能使用任何类型的SDLC、组织架构或符合这种管理的开发模型；敏捷、瀑布、看板管理或者一些组合形式都是可用而不违反SOA原则的。

此外，现代化的DevOps和云部署对SOA当然很有效，在这种系统中缩减组件数量并非必需。但在这些系统中，就算在最好的情况下，一些较大的组件也可能太过复杂而难以实现自动化，在最坏的情况下甚至完全无法实现。

举个例子，自动化部署的一个标准可能得需要100%通过一套自动化测试。这将确保现有的功能在新版本中仍旧可用（没有回归），而新功能也按照预期实现。随着功能交互越来越多，看似不相关的开发工作意外破坏现有功能某些方面的可能性有所增加。

此外一些测试可能很敏感，由于坏境或网络因素而出现失败个例。在100个测试案例中，5%的随机测试出现1%的失败率不会对普通发布造成大的阻碍。而在成千上万的测试中，同样的几率可能会造成较大影响，很多时候会造成至少一个随机故障。因此，即便要发布的版本没有什么实际的错误，也会因为无法通过这条标准而无法部署。

直接对比——建立购物车

我们来看一个在线购物网站。这个网站会有一些不同的功能，比如产品目录、用户帐号还有购物车等等。

使用SOA的开发公司一般会将购物网站拆分成主要的业务逻辑组，并将每个部分作为独立应用分别开发，最后集成到一起。

举个例子，整个购物车及其所有功能是由一大群人所开发的一个应用，他们需要了解整个购物车的工作机制，以便能够修改。在这个应用中，是代码负责显示物品、增加或移除购物车商品、查看库存、处理运费选项、处理税率计算、处理汇率、在更改时更新显示并将最终的订单细节发到用户邮箱里（还有其他等等）。用来显示购物车商品的代码包括在购物车应用中，可能与在浏览目录视图中用来显示商品名称的代码截然不同，从而造成需要维护的两套代码相似但不相同，还可能造成大应用UX上的某些不一致。

使用微服务架构的开发公司会将购物车切分成较小的任务导向服务。不再是购物车应用了，而可能是税率计算服务、添加/移除商品服务、运费服务、汇率服务和最终订单撰写服务。购物车功能可能也会用到一些常用的服务——它们会用在购物应用的很多地方，比如显示商品服务、显示产品图片服务、查看库存服务、用户支付偏好服务以及邮件服务。而“购物车”、“产品目录、“用户账户”之间并没有分界，通用代码被封装成各种服务，待需要时用在各种功能中。

当公司向中心授权组织请求展示产品时，必须修改展示来源，还得将浏览统计添加到购物应用中。在SOA架构中，产品目录应用和购物车应用必须独立各自更新，以体现变更。

需要对两个应用进行重测试，以确保变更没有影响其他功能，然后再重新部署。如果在这两个有改动的应用中还有其他功能有所变更，这一过程可能会进一步拖延（取决于开发进度的实现情况），而无法发布。一旦重新部署，负责展示的新机制速度可能明显要比旧机制慢，从而成为瓶颈。

延迟会导致客户投诉，然后问题被报告给管理层。有管理者决定要通过向整个产品目录应用与购物车应用部署额外实例，以处理额外的负载，应对延迟问题（如果有适当的监控与部署规则，这可能是自动执行的）。由于整个应用需要扩展，整个过程需要大量的额外处理能力与存储空间，在未执行额外部署的情况下，很多功能可能只能勉强运行。

而在微服务这里，只需进行一项改变——更新产品展示服务。这项服务可以独立进行快速的更改、测试与部署，而不会影响到大系统中的其他部分。此外，一旦发现瓶颈（很可能是通过自动化监控），无需向产品目录功能或者购物车服务所使用的其他服务部署更多实例，就能（可能是自动的）部署这项服务的额外实例，从而限制了支持额外部署所需的资源。

以上所有都是建立在想要发布一个大型在线商店，向各地各类人等售卖各类产品的假设上。如果假设你只想向美国境内的客户贩卖一种商品，并且只使用UPS作为物流的话。大量架构与复杂的在线商店都是没有必要的。

虽然仍需追踪用户信息、提供购物车与结算功能、展示产品信息与图片，甚至一些评论评价，但每一项功能所需都比复杂的在线商店要少得多。产品分类需求、计算不同运费选项的需求、系统处理增加/移除延时差异的需求还有所有其他综合商城所需的功能都不再需要。

在这种情况下，使用SOA将购物车、用户账户与产品展示组件与网站相集成可能要比使用微服务架构（像上面描述的那样有更为细致的组件定义）更有意义。在这种简单的设置中，不仅每个较大的组件被降低到复杂程度可控的范围内，而且实现这类网站所需的开发与其他员工的人数都会很少，无需将小型独立团队进行拓展。

相似却不相同

微服务与SOA有很多相同之处。两者都属于典型的、包含松耦合分布式组件的系统结构。但是两种架构背后的意图是不同的：SOA尝试将应用集成，一般采用中央管理模式来确保各应用能够交互运作。微服务尝试部署新功能，快速有效地扩展开发团队。它着重于分散管理、代码再利用与自动化执行。

总结：

哪种适合你的公司呢？完全取决于你的选择。

原文链接: Microservices Versus SOA in Practice 

译文转自：http://geek.csdn.net/news/detail/51826

深入阅读：浅析深究什么是SOA？

本文转自UltraSQL51CTO博客，原文链接：http://blog.51cto.com/ultrasql/1910480 ，如需转载请自行联系原作者