之所以单独耗费一章来说概念，是因为发现很多人没有搞清楚。我们从以下几个问题着手思考：
- 微服务和SOA的关系？
- 界限在哪里？
- 新提出微服务这样的概念是否有必要、有价值？
我之前也比较模糊，查看了不少资料，现在总算清楚多了。
SOA是很早就提出的概念了，当时场景是，将一个包含n多个功能的服务进行拆分，拆分成一个个的组件。我们看看百度百科给出的定义：
面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
我们可以看出，微服务强调的是拆，具体拆成什么样子，如何拆，没有做过多的规范，只是到“按功能拆分成组件”。而这正是微服务出现的契机，它提出了一套更详细、更明确的方案。
具体细化了如下内容：
- 服务的粒度：你是否可以修改一个服务并对其进行部署，而不影响其他任何服务？然而拆分成一个函数，更能满足这个要求，我们真要拆吗？这个通过领域驱动模型（DDD）来划分会更合理。DDD我会后续写一篇专门的文章介绍。
- 通讯协议：HTTP。比如，spring cloud就是通过REST风格的HTTP来通讯。
- 创建部署：用相对较小的工作量或方式来创建部署。目前，配合Docker是最佳实践。
- 自治性、自驱动：一个服务就是一个独立的实体。部署结构上，服务之间也应该尽量的独立。Docker用很小的代价，让微服务之间有了较高的独立性，二者互相成就。
所以，我们以微服务作为SOA的实践参考，但绝不拘于此。比如，实践中，RPC（如thrift、dubbo等）可能更合适，至少RPC性能更好，更面向对象而容易操作。
总结二者关系
SOA从服务需要拆分的角度出发，而微服务则更具体的确认了如何拆分的细节。微服务是SOA的一种最佳实践。
网友评论