入门级模式之细粒度SOA

细粒度SOA可以说是微服务的“大爆炸”时代。许多人认为，细粒度SOA架构风格起源于Netflix。在一开始，Netflix宣称他们构建的架构就是细粒度的SOA。对于SOA架构的实践者来说，细粒度SOA的特征从字面上就能知晓。细粒度SOA减少了SOA架构遇到的问题，并且它应用和SOA相同的原则，但将业务拆分为细粒度的服务，服务之间通过轻量级机制进行通信。实际上，目前大多数人仍然认为细粒度服务是微服务架构唯一的设计模式。

然而，在实施这种架构风格的过程中，Netflix和其他实践细粒度SOA模式的公司遇到了许多基本问题。当服务拆分地较小，并试图进行水平扩展时，就会出现一些困难：

1.之前只需要调用一次API，现在必须几十甚至上百次调用API。这种频繁的交互往往是非常低效的。（注：在灵长科技CEAMS系统中，服务之间的相互调用采用从Node.js全新的多线程机制中引入的高速异步消息通道，相比传统的进程间的API调用效率得到了极大的提升，因此这类开销在CEAMS系统中被降低到了最低程度）

2.过去您只需要管理少量的服务。但现在您需要管理成百上千的服务。之前的服务管理工具可能不再适用。

3.当数十、数百或数千的服务都可以查询或修改某个中心应用程序的状态时，通过任何一个微服务访问这个中心存储得到的状态都几乎不可能信赖其一致性。

实际上，实施微服务架构的过程中容易忽视以下几点挑战：低效的进程间通信，全方位的监控、管理和服务治理，以及系统状态的一致性。

在大多数情况下，细粒度SOA模式被应用为SOA服务集成的一种扩展，其中的每个服务都是为了与外部系统互联互通。从而形成对外部系统的强依赖性，使得变更速度变缓，并容易使得集成后的系统反映出应用程序的内部状态。

当你开始实施细粒度SOA模式时，请注意接下来将要发生的问题。上面所讲的困难会伴随着你的成功一起出现，你应该做好准备面对它们。当困难变得足够严重时，你将不可避免地需要寻找其他的模式。

问题：

粗粒度的服务很难灵活更改以适应需求的变化，并且传统单体架构的特性容易“阻碍团队前进”。

解决方案：

将服务拆分为更细粒度的微服务，减少特定的更改范围，从而使更改更容易发生。

应用：

通常拆分出来的每个细粒度微服务都有一个单独的用途。

影响：

1.服务请求交互次数增加

2.管理的服务数量越来越多

3.传统的监控解决方案不足

4.集成、测试和部署的自动化变得至关重要

5.微服务的编排成为必要

6.快速变更的能力得到提高

目标：

1.快速的敏捷变更

2.可伸缩性：理论上，你可以通过实施细粒度SOA模式提高可伸缩性，但实际上，除非支持自动化基础设施到位，否则可伸缩性往往会下降。

主要特点：

1.细粒度SOA模式在小范围内使用效果很好，但在大范围内会出现痛点。

2.重点是服务颗粒度要细，但通常没有考虑性能（例如可扩展性、可靠性等）。

3.以服务集成为导向，每个微服务依赖于外部系统。

4.为了实现快速的变更，存在着低效的进程间通信。（注：这也是基于docker容器技术的微服务架构的重大缺陷）

5.数据一致性和状态管理能力较差。

6.由于与现有SOA模式的相似性，SOA架构中存在的问题往往同样会发生。

如何与现有系统、SOA或API共存？

细粒度SOA模式非常类似于SOA和API主导的方法，并且能够利用现有系统的更多价值。与现有系统的共存模型也很简单。但也正因如此，细粒度SOA模式与现有系统共存时可能会产生较大的摩擦，因为现有IT资产的停滞变化可能会对服务拆分粒度造成阻力。