编者按：微服务的出现又掀起了一波新的技术热潮，很多人将微服务简单地理解为服务的分隔，于是提出了质疑：这和之前的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意在集成应用，而且使用集中管理模式来确保应用间的交互。而微服务意在更高效地部署新功能和扩展开发团队，并且组织的非集权化，代码重用和自动化。
总结如下：
原文出处：灵雀云
英文链接：https://www.voxxed.com/blog/2016/01/microservices-versus-soa-practice/
本文链接：https://www.yunweipai.com/7744.html
网友评论comments