《微服务设计》读书笔记（一）

什么是微服务

根据业务的边界来确定服务的边界，一个服务做好一件事。单个服务需要考虑内聚性，或者说单一职责原则，把因相同原因变化而变化的东西聚合到一起，把因不同变化而变化的东西分离开来。

微服务应该有多小呢

微服务应该足够小，但是不要过小。服务越小，独立性带来的好处就越多，但是管理大量的服务也会越复杂。在架构设计上需要平衡好服务独立性和服务治理的复杂度。

微服务的自治性

一个微服务就是一个独立的实体，可以独立部署，也可以作为一个操作系统进程存在。尽量避免把多个服务部署到同一台机器上。服务之间均通过网络调用来进行通信，从而加强服务之间的隔离性，降低紧耦合。多个服务之间应该尽量做到一个服务的部署不影响该服务消费方的变动。设计一个服务是应该考虑暴露什么，隐藏什么。

微服务的好处

1. 技术异构性，通过对服务的拆分，可以在不同服务中尝试不同的技术栈。尝试使用一种适合所有场景的标准化技术，会使得所有的场景都无法得到很好的支持。选择风险最小的服务来采用新技术，可以用最低的成本来进行新技术栈的尝试。
2. 使用微服务，可以改进服务的弹性。
3. 由于服务之间互相独立，可以对系统进行针对性的扩展。对压力比较大的模块进行多节点部署。
4. 简化部署，由于服务之间互相独立，耦合性较低。可以做到快速迭代。
5. 与组织结构相匹配，避免出现过大的代码库，提高生产力。
6. 可组合性，复用代码，根据需求对不同服务功能进行组合。
7. 对可替代性的优化，当一块代码或功能不需要时，可以删除或重写代码。

面向服务的架构 (SOA)

微服务架构是SOA的一种特定方法。

其他分解技术

共享库和模块，处理重用代码和拆分为不同模块时出现的问题，其实就是怎么在项目进行微服务化的时候减少代码量，而在减少代码量的同时又能保持尽量低的紧耦合。

微服务不是架构过程中的银弹

没有任何一种架构或方案能彻底解决软件开发种的所有问题，任何一种方案都有其优点和局限性，在架构设计和实际开发中需要扬长避短。