Microservices VS. SOA

什么是微服务？

微服务是一种架构设计模式。在微服务架构中，业务逻辑被分解为一系列小的、松耦合的、分布式组件，组合起来造成大型的应用。每一个组件都被称为一个微服务，每一个微服务负责一个任务或功能。每一个微服务可能被其它一个或多个微服务调用，来执行特定的任务，好比用一种统一的方式来处理搜索、图片展现，或其它须要在应用的不一样场景下开发或维护多个版本的状况。

使用微服务架构还能造成一种机制来提升新手的生产率，减小新功能推向市场的时间。每一个微服务有一个有边界的代码库，以及关联的工具集；开发者不须要了解整个大型的复杂系统就能上手，只须要知道与其微服务相关的部分就好。 

微服务能够被很快开发出来，由于他们可使用手边最适合的语言和工具集，不须要担忧应用其它组件的技术选型，也不用担忧其余开发者对这些语言和工具是否了解。

为了充分发挥小团队轻便灵活的特色，团队须要有自治权，他们要快速作决定，而且屏蔽外部的监管。为了达到这个目的，整个工做组应该包含了从产品管理到发布和运营的全部相关人员。因为微服务组件是松耦合的，经过API进行通讯，对于大部分决定来讲，高度的自治权并不影响整个应用的功能。只要微服务向外开发了本身的API，并能被API调用执行对应的功能，整个系统就能运行良好。

因为一个微服务架构中有这么多独立的组件，在一个弹性的网络环境（好比公有云或私有云）中使用现代的DevOps方式，成为了保证整个系统在大多数状况下稳定运行的重要保证。尤为是在不少状况下，健康和负载的自动监控，以及附加实例的自动部署变得相当重要了。

 

什么是SOA？

SOA（Service Oriented Architecture）是一种集成多个组件（一般是粒度更大的应用）的方式，他们组合起来能够造成一个彼此协做的系统。每一个组件专门从头至尾地执行一个完整的业务逻辑，一般涉及多个特定的任务和功能共同完成一个更大的动做。组件是松耦合的，但这不是必要条件。

虽然没有严格的需求，但SOA是典型的集中式管理：一个审核委员会，一个首席架构师或架构委员，严格定义了系统每一个组件应该作什么，以及如何去作。若是组件使用的语言和工具集不是集中定义和统一的话，一样类型的功能可能会被分开定义或写在多个组件中。SOA对软件生命周期管理（SDLC）的模式和组织架构都没有严格的限制，开发模式方面：敏捷（agile），瀑布（waterfall），看板（kanban），或者几种模式的组合，都不违背SOA的原则。

并且，虽然DevOps和云计算等新技术对于SOA颇有用，但因为这种系统的组件数量很少，因此并非本质需求。可是这些系统中一些更大的组件可能会至关复杂，自动化很是困难，甚至是不切实际的。

好比，自动化部署成功的标准多是100%地经过一系列自动化测试。这保证了现有的功能在新的版本中依然正常工做，而新的功能达到预期的目标。随着功能的交互愈来愈多，现有功能的某些方面，极可能会被看起来并不相关的开发工做意外打散。

并且，一些测试可能会因为环境或网络问题失败。好比，若是100个测试的失败率是5%，失败的时间比率是1%，并不会影响正常的发布。但若是测试的数量成千上万，相同的比例产生的影响就不容小觑了。所以，就算候选发布版本并无问题，也常常会在失败在不知足部署条件上。

直接对比：以电商网站为例

下面以一个电商网站为例，来对比SOA和微服务架构。电商网站一般有不少功能模块，基本的模块包括：产品目录，用户帐户，购物车等。

一个基于SOA技术的开发团队，一般会将这个网站按业务逻辑拆分为几个分别的应用，而后集成到一块儿。

好比，整个购物车及其全部功能会被放到一个应用中，负责这个应用开发的团队中，每一个人都要对整个购物车的业务了如指掌才行。应用内的代码要实现诸如产品展现，从购物车中添加和删除条目，库存查询，送货处理，计税处理，帐单处理，展现更新，以及将最后的订单详情发给用户等功能。在购物车应用内的产品展现，与产品目录应用中的产品实现的功能很是相似，但代码因为分属2个应用，由不一样的团队维护，可能彻底不一样。相似的功能却要维护两份彻底不一样的代码显然并不合理，并且在大型应用中极可能形成不一致的问题。

而基于微服务架构的团队，会将购物车拆分为更小的面向任务的服务，好比：一个计税服务，一个添加/删除条目的服务，一个送货服务，一个帐单服务，以及一个造成最终订单的服务。购物车还会用到一些通用服务，好比：产品展现服务，产品图片展现服务，库存查询服务，用户支付选择服务，以及邮件服务。这些通用的代码会被封装为服务，不论是『购物车』，『产品目录』仍是『用户帐户』可使用调用这些服务。

假设公司决定经过一个第三方为产品的图片加上license，那么图片的地址都要更改，浏览的数据统计也要被加到应用中。在SOA架构中，这个更改会同时影响到产品目录应用和购物车应用。两个应用都要从新测试，才能被部署，若是其中一个应用的更新不能进入部署，就会影响整个应用的更新部署。就算部署成功了，很显然新的图片服务机制比原来要慢了，可能会成为瓶颈。

你们意识到这个问题后，可能会经过部署更多实例的方法来解决，固然产品展现应用和购物车应用都要增长实例（若是有合适的监控和部署方案的话，这个过程多是自动的）。这意味着整个应用都要被扩展了，虽然不少功能并不须要额外的资源。

而在微服务的世界中，这种状况只须要更新一个服务：产品图片展现服务。在不影响系统其它部分的条件下，修改、测试和部署一个服务是很快的。并且某个服务出现了瓶颈的话，能够独立地扩展，避免了资源的浪费。

以上假设都基于你要发布一个大型的电子商务网站，用户量很大，而且分布地域很广。若是你只卖一个产品，而且顾客限定为美国地区使用UPS的顾客，许多电商网站的基础设施和复杂度都不在你的考虑范围内。

你依然要跟踪用户信息，提供购物车和结帐功能，并且要有一个页面展现产品信息，图片，以及一部分用户评论，可是全部这些功能都要比大型电商简单不少。不须要考虑产品目录，送货选项，添加或删除商品，以及全部其它多种商品的电商须要考虑的问题。

这种状况下，使用SOA的架构更适合，由于每一个组件的复杂度都下降到了可管理的程度，并且实现这种网站所需的开发人员数量也很少，免去了要靠小微型的独立团队来扩展规模的问题。

相似可是不一样

因此微服务和SOA有不少相似之处：两种系统都由松耦合的分布式组件构成。可是两种架构背后的意图是很是不一样的：SOA意在集成应用，并且使用集中管理模式来确保应用间的交互。而微服务意在更高效地部署新功能和扩展开发团队，而且组织的非集权化，代码重用和自动化。

总结以下：

特性	SOA	Microservices
组件大小	大块的业务逻辑	单独的任务或小块的业务逻辑
耦合度	一般是松耦合	必须是松耦合
组织结构	任意	小型的，跨职能团队
管理	集中式管理	非集权化管理
目标	保证应用间的相互交互	为了高效地部署新功能和扩展开发团队

原文连接：https://www.voxxed.com/blog/2016/01/microservices-versus-soa-practice/