第一章 微服务

什么是微服务？

微服务就是一些协同工作的小而自治的系统。

微服务有哪些特点？

• 很小，专注于做好一件事：保证代码的内聚性，遵循单一职责原则。到底要小到多小没有确定的定论，大佬认为，通常一个微服务要小到可以两周内完全重写。

  如何确定足够小了：

  • 自己不再感觉代码库过大：不要一味追求小，而应该根据自己的感觉，如果你认为代码库不过于大了，那就够小了
  • 和团队结构相匹配：如果巨大的代码库由一个小团队维护，显然是无法正常维护的，此时就需要对其进行拆分，拆分到和团队结构相匹配为止。

• 自治性：微服务之间应该保持独立性，服务之间均通过网络调用进行通信，加强隔离，避免耦合。微服务之间通过API进行通信，API的实现技术应该避免与消费方耦合，应该选择与具体技术不相关的API实现方式。

微服务有何好处？

• 技术异构性：在一个由多个服务相互协作的系统中，不同的服务之间可以采用最适合服务场景的技术，不要一味追求技术的统一。
• 弹性：单一的系统，如果服务不可用，所有的功能都会不可用，而微服务系统中，一个组件不可用，且在没有导致级联故障的情况下，其他功能仍然是可用的。
• 扩展：庞大的单块服务只能作为整体进行扩展，即使只有一小部分存在性能问题，也需要对整个服务进行扩展。而在微服务的场景下，只需对需要扩展的服务扩展即可。
• 简化部署：在庞大的单块服务中，即使只修改了一行代码，也还是需要对整个服务进行重新部署，这种部署影响大、风险高，因此相关人员会刻意减少变更次数，多次变更一次发布。这种策略一方面不利于服务的快速迭代，其次是两次发布的差异性越大，出错的几率就会更高。
• 与团队结构相匹配：在小型代码库上工作的小团队会更加高效，过大的代码库和过多的团队无疑会导致效率降低。微服务可以很好的将架构与组织结构相匹配，从而提高生产效率。
• 可组合性：微服务架构中，系统会开发很多接口供外部使用，当需求改变时，可以通过不同的接口组合使用，从而在不变更服务代码的情况下，实现新需求。
• 可替代性优化：如果一个系统过于庞大，就会导致其变更的难度大、风险高，而随着时间推移，这种问题会越发凸显出来。而当使用了微服务，对某一服务重新实现的难度会大大降低，从而使系统的迭代更新速度更快、替代性更好。

其他概念扩展：

• 单一职责原则(Single Responsibility Principle)：把因相同原因而变化的东西聚合在一起，而把因不同原因变化的东西分离开来。其核心思想就是一个模块、类、方法或是服务，最好只干一件事，想了解更多内容参见：小话设计模式原则之：单一职责原则SRP

• 面向服务的架构(Service-Oriented Architecture, SOA)：SOA 是一种设计方法，其中包含多个服务，服务之间通过配合，最终向外提供一系列功能。而服务通常独立部署，服务之间通过网络调用，而非进行内调用。更多内容可参考：SOA 、 如何通俗易懂地解释什么是SOA？