【SpringCloud】微服务的扩展性及其与 SOA 的区别

一、微服务的扩展性

由上一篇文章（没看过的可点击传送阅读）可知，微服务具有极强的可扩展性，这些扩展性包含以下几个方面：

性能可扩展：性能无法完全实现线性扩展，但要尽量使用具有并发性和异步性的组件。具备完成通知功能的工作队列要优于同步连接到数据库

可用性扩展：CAP 理论表明，分布式系统无法同时提供一致性、可用性和分区容错性保证。许多大规模 Web 应用都为了可用性和分区容错性而牺牲了强一致性，而后者则依赖于最终一致性来保证

维护可扩展：软件和服务器都需要维护。在使用平台的工具监控和更新应用程序时，要尽可能自动化

成本可扩展：总成本包括开发、维护和运营支出。在设计一个系统时，要在重用现有组件和完全性开发组件之间进行权衡。现有组件很少能完全满足需求，但修改现有组件的成本还是可能低于开发一个完全不同的方案的。另外，使用符合行业标准的技术使组织更容易聘请专家，而发布独有的开源方案则可能帮助组织从社区中挖掘人才

二、微服务与 SOA 的区别

面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来

接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言

这使得构建在各种各样系统中的服务可以以一种统一、通用的方式进行交互

都是服务化，那微服务与 SOA 有什么区别呢？

相同点：

需要注册中心，实现动态的服务注册发现机制

需要考虑分布式下面的事务一致性，CAP 原则下，两段式提交不能保证性能，事务补偿机制需要考虑

同步调用还是异步消息传递，如何保证消息可靠性？SOA 由 ESB 来集成所有的信息

都需要统一的 Gateway 来汇聚、编排接口，实现统一认证机制，对外提供 APP 使用的 RESTful 接口

同样要关注如何在分布式下定位系统问题？如何做日志跟踪？

差异点：

是持续继承、持续部署？对于 CI、CD（持续集成、持续部署），这本身和敏捷、DevOps 是交织在一起的，所以更倾向于软件工程的领域而不是微服务技术本身

使用不同的通信协议是不是区别？微服务的标杆通信协议是 RESTful，而传统的 SOA 一般是 SOAP，不过目前来说采用轻量级的 RPC 框架（Dubbo、Thrift、gRPC）非常多，在 Sprin gCloud 中也有 Fegin 框架将标准 RESTful 转为代码的 API 这种仿 RPC 的行为，这些通信协议不应该是区分微服务架构和 SOA 的核心差别