（一）初步认识微服务

目录

微服务的特征

微服务诞生背景

单体架构和微服务架构

微服务的优势和不足

---

微服务的特征

▶单一职责：只把紧密相关的服务放在一起，无关的业务独立出去；

▶轻量级的通信：微服务与微服务之间的通信应该使用轻量级的通信，做到平台无关和语言无关；

▶隔离性：每个微服务运行在自己的进程中，不会相互干扰；

▶有自己的数据：业务数据的独立性，每个微服务都有自己的独立的数据存储系统，以降低数据结构的复杂度；

▶技术的多样性：可以由开发人员来选择最适合的技术来实现业务需求，只要能提供出应有的API。

 

微服务诞生背景

▶ 互联网行业的快速发展（需求变化快，用户数量变化快）；

▶ 敏捷开发，精益方法深入人心（用最小的代价做最快的迭代，看到有用的反馈，即频繁的修改、测试、上线）；

▶ 容器技术的成熟（Docker的出现，有效解决了由于微服务数量的庞大而导致的运微瓶颈 ）

 

单体架构和微服务架构

说明：上例中只是为了理解和区别单体架构和微服务架构，对于微服务的划分不一定是准确的。

 

 

微服务的优势和不足

微服务的优势：

 ▶独立性：微服务从构建-部署-扩容-缩容-容错-数据库都是单独管理的，每个服务之间都是独立的，容错上当一个微服务出现问题时，它只会影响它自己，并且很容易快速的恢复，它并不会影响整个的服务，提高了整个服务的可用性；在数据上每个微服务有独立的数据库，避免了原来修改一个数据结构要小心翼翼，生怕影响了谁，但这些小心翼翼是徒劳的，因为有时候无法预计会影响到谁，现在把数据库独立出来，表的结构会相对简单，表的数量也会相对减少。

 ▶敏捷性： 对使用者来说，微服务暴露了接口会相对简单，功能单一，有清晰的API  ，对使用者理解起来会相对简单，同时也可以非常快速的应对变化，比如有一个新需求的时候，可以很容易的找到应该修改那个微服务。

 ▶技术栈灵活：每个微服务理论上都应该有自己独立的技术栈，不会受到其他微服务的影响，只需要保证自己的API接口不变就OK了，这样的架构非常容易接收新架构，服务重构也会变得非常简单。

 ▶高效团队：微服务的团队规模一般相对较小而灵活，每个团队只负责自己的微服务，若有调整只需要几个人开个小会即可。

微服务的不足：

 ▶额外的工作：最重要的一条就是服务的拆分，如何把服务拆分成一个个微服务，这是一个非常深的学问。

 ▶数据的一致性：单体架构只有一个数据库，可以使用事务来进行多表的级联修改或删除，很容易达到数据的一致性。而在微服务架构里，每个微服务有它们自己的数据库 ，即使我们在拆分微服务的时候，保证数据库的联表操作尽量在同一个微服务里，但是也很难保证没有依赖的情况，一旦出现，就会给我们的数据一致性带来挑战。

 ▶沟通成本：因为微服务API的改变而带来。 在单体架构中，想要修改一个接口，可以把调用这个接口的方法一并修改掉。但是在微服务中想要修改的地方已经不是你负责甚至不是你们组负责，这个时候你就要推动其他人或其他组的人来完成这次修改，如果这种修改比较多的情况下，其中的沟通成本是可想而知的。