什么是微服务系统？
保留所有版权，请引用而不是转载本文（原文地址 https://yeecode.top/blog/141/ ）。
在分布式应用里，每个子应用存在的意义，是完成分布式应用中的一部分功能——子应用和应用之间是严格的从属关系。但恰恰是这种严格的从属，可能造成性能浪费。
举个例子：有个应用 A，包含三个子应用，A1 管订单、A2 管库存、A3 管金额核算。当我们要做销售金额核算（涉及订单管理和金额核算）时，得调用 A，而 A 下的 A2（库存）和这次操作无关，就这么闲置了。换句话说，应用 A 干活时，无关的那些子应用是闲着的，性能没发挥出来。
这就好比商店只卖"汉堡+可乐+薯片"的固定套餐，你不要可乐，买这个套餐也是浪费。避免浪费的办法，是允许你自由组合着买。
于是思路就变了：做销售金额核算时，直接调 A1 和 A3；做库存资产核算（涉及库存管理和金额核算）时，直接调 A2 和 A3。不再在子应用外面套一个应用 A，而是让各个子应用直接对外服务，外部调用者按需自由挑选。这就组成了微服务系统。
在微服务集群里，每个微服务子应用都是完备的、可独立对外服务的，也能自由组合后对外服务，灵活性很高。图 1展示了微服务集群的示意。
每个微服务子应用对各类资源的依赖程度不同、被调用的频次也不同，因此我们可以针对每个微服务去做资源配置、集群配置，提升它们各自的时间效率、资源利用率和容量。
在单体应用内部，任何模块都可能和其他模块耦合；而在微服务集群里，每个微服务内聚性高、和其他微服务的耦合很低。所以只要对外接口不变，微服务就能自由改内部逻辑，由独立团队开发、维护、升级，不用去了解别的微服务的实现细节。这有利于提升系统的成熟度、可用性、容错性和可恢复性。
在 AI 帮我们快速拼出业务功能的今天，怎么把系统拆成边界清晰、能独立演进的服务，恰恰是衡量一个架构好坏的关键。聊完微服务系统的来龙去脉，如果你觉得架构这些话题有意思，强烈推荐一本书《高性能架构之道（第二版）》。
这是一本理论联系实际的架构书，系统讲了怎么从顶层把软件架构好：覆盖分布式、并发编程、数据库调优、缓存、IO、高可用、前端性能优化等众多知识，最后还拿一个真实项目完整走了一遍架构全过程，把书里的方法真正落了地。
这本书还在台湾地区出了繁体版，叫《巨型服务架构》——繁体版嘛，贵得有点离谱。
就先聊到这儿。
我是软件架构师易哥。可以关注我，我会偶尔冒个泡，分享点编程干货！
可以访问个人知乎阅读更多文章：易哥（https://www.zhihu.com/people/yeecode），欢迎关注。
作者书籍推荐
