soa 如何理解 SOA 和微服务的区别

微服务是一种架构设计模式。在微服务架构中，业务逻辑被分成一系列小的、松散耦合的分布式组件，这些组件共同构成了一个更大的应用程序。每个组件被称为一个微服务，每个微服务执行一个单独的任务或者负责整个体系结构中的一个单独的功能。每个微服务可以由一个或多个其他微服务调用，以执行大型应用程序需要完成的特定任务；该系统还为任务执行提供了统一的解决方案，如搜索或显示图片，或其他可能需要多次执行的任务，并限制应用程序中的不同位置生成或维护同一功能的多个版本。

使用微服务架构还提供了一种机制，可以提高新开发人员的生产力，减少新功能的推广时间。每个微服务的代码库和相关工具集是有限的；开发人员不再需要理解庞大而复杂的系统，只需要理解他们所做的微服务的子集，然后他们就可以为生产力做出贡献。因为不需要考虑在应用程序的现有部分使用什么语言或者工具集，或者更大的应用程序的其他开发人员是否知道这些语言和工具，只需要使用当前任务中最有优势的工具，所以微服务开发的非常快。

为了充分利用速度优势，让小团队发展成为可能，团队需要自主性；他们必须能够迅速做出决策，避免过度监管。为了支持这一点，工作团队应该包括所有相关人员，从产品经理到发布操作员。因为微服务组件是松散耦合的，通过API进行通信，所以各方在大多数决策上都有高度的自主权，不会影响应用的整体功能。只要微服务可以发布API，并使用这些API来执行所需的功能，整个系统就会运行良好。

因为一个微服务架构中有很多独立的组件，所以在灵活的网络(如公有云或私有云)上使用现代的DevOps在大多数情况下保证整个系统的正常运行尤为重要。特别是，在许多情况下，与自动部署额外实例相关的自动运行状况和负载监控(以最小化未充分利用的实例)变得非常重要。

面向服务架构(SOA)是一种集成多个大型组件(通常是应用程序)的机制，它们将形成一个协作套件。一般来说，每个组件都会从头到尾执行一个完整的业务逻辑，通常包括完成整体大动作所需的各种具体任务和功能。组件通常是松散耦合的，但这不是SOA架构模式的要求。

虽然没有严格的要求，但是SOA通常使用某种集中管理，例如评审委员会、主架构师或架构委员会，来严格定义每个系统组件应该做什么以及如何执行。相同类型的功能可以根据需要在多个组件中单独定义和记录，而每个组件使用的语言和工具集可以是也可以不是集中确定和统一的。SOA可以使用符合这种管理的任何类型的软件开发生命周期、组织结构或开发模型；敏捷、瀑布、看板管理或一些组合形式都是可用的，而不违反SOA原则。

另外，现代的DevOps和云部署对于SOA当然是非常有效的，不需要减少这个系统中的组件数量。但是，在这些系统中，即使在最好的情况下，一些较大的组件也可能过于复杂而无法实现自动化，在最坏的情况下，根本无法实现。

例如，自动化部署的标准可能需要100%通过一组自动化测试。这将确保现有功能在新版本中仍然可用(没有回归)，并且新功能按预期实现。随着功能的交互越来越多，看似不相关的开发工作更有可能会不小心破坏现有功能的某些方面。

此外，有些测试可能是敏感的，由于环境或网络因素的影响，会出现一些故障。在100个测试用例中，5%的随机测试有1%的失败率，不会对一般的发布造成很大的阻碍。但是在成千上万次的测试中，同样的概率可能会产生很大的影响，很多情况下会造成至少一次随机失败。因此，即使要发布的版本没有实际错误，也不能部署，因为它不能通过这个标准。

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

使用SOA的开发公司一般会将购物网站划分为主要的业务逻辑组，将各个部分开发为独立的应用程序，最后将它们集成在一起。

比如整个购物车及其所有功能都是一大群人开发的应用程序，他们需要了解整个购物车的工作机制，以便修改。在此应用程序中，代码负责显示项目、添加或删除购物车项目、检查库存、处理运费选项、处理税率计算、处理汇率、在更改时更新显示，以及将最终订单详细信息发送到用户的邮箱(等等)。用于显示购物车产品的代码包含在购物车应用程序中，这可能与用于在浏览目录视图中显示产品名称的代码完全不同，导致需要维护的两组代码相似但不同，并可能在大型应用程序UX中导致一些不一致。

使用微服务架构的开发公司会将购物车分成更小的面向任务的服务。而不是购物车应用，可能是税率计算服务、货物添加/移除服务、货运服务、汇率服务、最终订单撰写服务。购物车功能也可以使用一些常见的服务——它们将被用在购物应用的许多地方，如展示商品服务、展示产品图片服务、检查库存服务、用户支付偏好服务和邮件服务。但是“购物车”、“产品目录”和“用户账号”之间是没有边界的，一般的代码封装到各种服务中，需要的时候用在各种功能中。

当公司请求中心授权机构展示产品时，必须修改展示来源，并将浏览统计添加到购物应用中。在SOA架构中，产品目录应用程序和购物车应用程序必须独立更新以反映变化。

在重新部署之前，需要重新测试两个应用程序，以确保更改不会影响其他功能。如果在这两个修改后的应用程序中改变了其他功能，这个过程可能会进一步延迟(取决于开发进度的实现)，并且无法释放。一旦重新部署，负责显示的新机制可能明显比旧机制慢，从而成为瓶颈。

延迟导致客户投诉，然后向管理层报告。一些经理决定向整个产品目录应用程序和购物车应用程序部署额外的实例，以处理额外的负载和延迟问题(如果有适当的监控和部署规则，这可能会自动执行)。由于整个应用需要扩展，整个过程需要大量额外的处理能力和存储空。没有额外的部署，很多功能可能只能勉强运行。

在微服务中，只需要一个改变——更新产品展示服务。该服务可以独立地快速更改、测试和部署，而不会影响大型系统的其他部分。此外，一旦发现瓶颈(可能通过自动监控)，就可以部署该服务的其他实例(可能是自动的)，而无需向购物车服务使用的产品目录功能或其他服务部署更多实例，从而限制了支持其他部署所需的资源。

以上都是基于我们想发布大型网店，向各地的人销售各种产品的假设。假设你只想把一个商品卖给美国的客户，只用UPS做物流。大量的架构和复杂的网店是不必要的。

虽然仍然需要跟踪用户信息，提供购物车和结算功能，显示产品信息和图片，甚至一些评论，但每个功能需要的比复杂的网店少得多。对产品分类的要求，对计算不同运费选项的要求，对系统处理延迟差异增加/消除的要求，以及综合商城所需的所有其他功能都不再需要。

在这种情况下，使用SOA将购物车、用户账户和产品展示组件与网站集成可能比使用微服务架构(如上所述有更详细的组件定义)更有意义。在这种简单的设置下，不仅每个大组件降低到可控的复杂程度，而且实现这种网站所需的开发和其他员工数量也非常少，不需要扩展小的独立团队。

微服务与SOA有许多相似之处。两者都属于典型的松散耦合分布式组件的系统结构。但是两种架构背后的意图是不一样的:SOA试图集成应用，一般采用集中管理的模式，保证所有应用都可以交互。微服务试图快速有效地部署新功能和扩展开发团队。它侧重于分散管理、代码重用和自动执行。

总结: