SOA 与 MSA（微服务架构）

http://bbs.chinaunix.net/thread-4255092-2-1.html

1. 你了解微服务吗？SOA和微服务有何差异？
微服务架构被认为是目前最适合开发高可扩展性应用的架构风格，微服务架构致力于解决大型、复杂的应用的各种问题。它是一种基于服务的架构，这些服务可独立部署，作为基础的组件。微服务架构在整个开发、测试等开发周期中提供了更好的控制，但它在服务分类方面有一些限制。微服务架构还使用了服务间的通信协议（REST、JSON等）。
SOA架构可以由多种定义方式，这是因为SOA架构风格一直在不断地发展演进。它为企业级软件的复杂组合带来了秩序——通过把它们表示为服务的集合。SOA还使用了服务通信协议，SOA可以被认为是微服务的超集。
SOA架构依赖于共享数据模型。此模型在大量数据结构和模型和分层之间有复杂的关系。SOA的分层组织结构有利于服务协调和消息通信功能。
SOA是基于共享数据模型的，因此，可以预估它在服务和其它系统组件之间存在数据紧耦合的现象。这使得它难以做改变。一些附带的重测是必要的，以确保改变不影响现有的任何服务。
微服务架构存在上下文边界的概念，这使得它在单个服务和数据之间存在关联。
SOA架构的多层模型以中央的消息通信中间件层为主要特征。而对于微服务架构，在组成应用的各种服务之上就存在一个非协调的API层。
通过一个中央集线控制器，SOA维护了服务执行的顺序。而微服务使用了服务间的通信协议来维护服务执行的顺序。
SOA架构致力于解决在复杂的企业系统中的异构应用，促成跨应用和功能的共享服务。而微服务架构是面向基于Web的、更小的、不太复杂的应用程序的最佳架构方式，这些应用程序不需要明确的服务协调。

2. 到底在什么样的情况才适合使用微服务架构？
如果遇到了以下的情况，应该采用微服务架构：
1）系统越来越庞大，新功能开发或修改功能变得越来越耗时
2）系统的复杂度极高，模块间紧耦合严重，整体扩展性差
3）系统性能不高，通过扩展也难以提升性能
4）系统的可维护性越来越差

3. 服务与服务之间的事务怎么做?接口的调用权限如何控制,粒度在方法级别的？
我通常是这么解决的。在基础服务的上层封装面向事务处理的服务（这里我称为A服务），A服务依赖于下层的多个基础服务，一个A服务就是一个完整的事务处理过程，它内部是调用下层的多个服务共同完成功能的。如果A服务执行失败，则做相应的回退等处理；如果A服务执行成功，那么继续。
微服务架构的服务之间的调用，可以通过REST接口，还可以用RPC、消息通信等方式。以REST接口为例，服务间通过内网或专线方式进行调用，以保证速度。对外则使用API网关来做访问控制。

4. 为什么有人说“玩不起”？较比普通架构需要多做那些工作？
微服务架构要设计好并不容易。我的建议是根据具体的需求具体分析，通用的原则也不少。

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

难以对比 SOA 和微服务的原因在于，它们的定义留有很大的解释空间。如果您仅拥有这两个概念的表面知识，可能会觉得它们很相似。一些关键方面（比如组件化、解耦和标准化通信协议）描述了最近几十年的大部分软件举措，所以我们需要进行更深入地分析。

考虑以下简单定义：

• 微服务架构是一种构造应用程序的替代性方法。应用程序被分解为更小、完全独立的组件，这使得它们拥有更高的敏捷性、可伸缩性和可用性。
• SOA将应用程序的功能公开为更容易访问的服务接口，使得在下一代应用程序中使用它们的数据和逻辑变得更容易。
  
  
  
  

如下图演示了这些定义。SOA 似乎拥有 企业范围，应用程序在该范围内彼此通信。SOA 通过应用程序之间的标准化接口来公开服务。微服务架构似乎拥有 应用程序范围，仅关注一个应用程序内的结构和组件。