16.凤凰架构：构建可靠的大型分布式系统 --- 向微服务迈进

Posted 2022-03-25 enlyhua

第16章　向微服务迈进
16.1　目的：微服务的驱动力
	硬件的成本能够持续的下降，而软件开发的成本则不可能。

16.2　前提：微服务需要的条件
	1.决策者与执行者都能意识到康威定律在软件设计中的关键作用
	2.组织中具备一些对微服务有充分理解、有一定实践经验的技术专家
	3.系统应具有以自治为目标的自动化与监控度量能力
	4.复杂性已经成为制约生产力的主要矛盾

16.3　边界：微服务的粒度
	1.微服务粒度的下届是它至少满足独立---能够独立发布、独立部署、独立运行与独立测试，内聚---强相关的功能与数据在同一个服务中处理，完备---
	一个服务包含至少一项业务实体与对应的完整操作。

	软件项目中沟通的成本 = n*(n-1)/2

	2.微服务粒度的上界是一个 2 Pizza Team 能够在一个研发周期内完成的全部需求范围。

16.4　治理：理解系统复杂性
		治理这个词切确的含义是让产品(系统、业务、流程、服务)能够符合预期的稳定运行，并能够持续保持在一定的质量水平上。该定义把治理具体分解为
	"正确执行"(让软件符合预期的运行)和"持续保持"(让软件保持一定质量水平的运行)2个层次的要求。

	16.4.1　静态的治理
		复杂性来源：
			1.复杂性来自认知负荷
			2.复杂性来自协作成本

		软件规模小的时候微服务复杂度高于单体系统，规模大的时候相反。

	16.4.2　发展的治理
		架构腐化：架构腐化只能延缓，无法避免。

		架构腐化与生物的衰老过程很像，原因都来自于随时间发生的微妙变化。团队初期选择的解决方案通常能够解决技术选型时就能够预料到的那部分困难，
	但真正的困难的地方在于，随着时间的流失，团队对该项目质量的保持能力会逐渐下降。一方面是 高级技术专家不可能持续参与软件稳定后的迭代过程，反过来，
	如果持续绑定在同一个达到稳定后的项目上，也很难培养出技术专家。老人的退出、新人的加入使得团队总是需要理解