1. 前言
本书初始是一本在线阅读物，然后逐步发展出极客时间的课程，以及实体书籍。
截止目前(2023-03-05)，这本在线读物距最开始的公开已经快三年了，但我第一次知晓它的时候，已经是前年年底了，而且还是从因为一个朋友询问对这本书的看法时，才知晓有它的存在。
其实一开始我并没有阅读的打算，自几年前阅读过多本诸如《从零开始学架构》，《亿级流量网站架构核心技术》，《大型网站技术架构》，《大型网站技术架构演进与性能优化》等书籍，加上过去这些年一直都是在传统软件行业里进行职业生涯。有感于实际应用范围和应用深度的限制，逐渐将职业生涯的关注点由微服务技术架构转向了软件工程方面。
最终我还是购买了本书的纸质版本，并在过去一个月里将其读完。因为发现这本书的作者是周志明博士，而我之前拜读过他的那本《深入理解 Java 虚拟机：JVM 高级特性与最佳实践（第二版）》，而那本书里，作者展现出来的专业性让人印象深刻。
2. 全书印象
- 作者非常博学。作者在书中表现出的对于行业最新动态的认识，某项技术相关发展史的了解，相关技术趣闻的引用，业内大牛观点的佐证，无一不在时刻验证着这一点。然后笔者仿佛又找回了年轻时对于顶级程序员膜拜和向往 —— 怎么他们能知道这么多，而且还能理解得这么深刻？ 不过，现在的我，血还能热一热，但往往转身就凉了 —— 哎呀，这个知识的前置知识太多了，就先这样，会用就行了；哎呀，这个技术对于我们这种小公司太高端，等用到再说吧。
- 相较于笔者阅读过的架构类书籍，本书更为厚重，尤其是关于微服务这一块的。这里以远程调用举例，在其他书籍里，我看到的都是什么熔断，降级，调用要设置超时等等这些非常细节性的技术介绍，但在本书中，作者在介绍这些之前，从整个相关软件历史上的最初阶段开始讲解，通过带领读者一步步地从问题到探索，从探索到结论，从结论到优化，逐渐将相关技术当下的进展呈现在受众面前，让读者不禁感慨 —— 原来如此。
- 作者是一个非常有信念的人。首先本书直接使用开源软件的方法进行创造，也即使所谓的"开源写作"，迄今为止，已近三年；而且在写下这段文字的时候，这本开源书籍最后一次更新是在2023年2月5号。其次作者在本书的附加章节程序员之路里描述的 —— 将思考具象化。
开篇中，我便提到了撰写这门课程的目的：做技术不仅要去看、去读、去想、去用，更要去说、去写。将自己“认为掌握了的”知识叙述出来，能够说得清晰有条理，讲得理直气壮；能够让他人听得明白，释去心中疑惑；能够把自己的观点交予别人的审视，乃至质疑，在此过程之中，会挖掘出很多潜藏在“已知”背后的“未知”。
这个目的也是它成为免费公益课的原因：课程本身就是我对自己知识体系的整理的成果，是我思考的具象化表现，这件事情中，我自己是最大的受益者，其后的极客时间课程，以及出版的纸质书籍，都可算是额外的收获，这样看来，经济上的回报也就不那么重要了。
一个人有所观点，有所认识不是什么难事，现在信息来源如此广泛，段视频都已经是国民级应用了，但为了这个所谓的观点和认识，你的行动和表现是什么？ 我觉得这才是决定这个所谓的观点和认识是真正属于你自己的，还是只是你觉得它是你自己思考出来的；而这些行动和表现才是最终决定你是一个什么样的人，一个你在别人眼中是什么样的人。
3. 全书摘记
上面啰嗦那么多，本小节就简要摘记写对于笔者而言比较记忆深刻的观点。
3.1 演进式设计
全书看下来，最有启发性的，还得是这个用全书书名来表达的观点 —— 系统的架构应该像凤凰一样，涅磐重生；要从心底接受一个具有良好设计的系统，应该是能够被报废的。
- 大型软件的建设是一个不断推倒重来的演进过程，前一个版本对后一个版本的价值在于它满足了这个阶段用户的需要，让团队成功适应了这个阶段的复杂度，可以向下一个台阶迈进。
- 复杂性本身不是洪水猛兽，无法处理的复杂性才是。
- 敏锐地捕获到生产力的变化，随时调整生产关系，这才是架构师治理复杂性的终极方法。
3.2 微服务边界的划分
虽然买了好几本DDD相关的书籍，但一本都还没看完过，另外一个更重要的是在实际工作中完全没有试点的机会。
所以本书中对于微服务粒度划分，相较于其他书籍而言，更为具体的建议就显得弥足珍贵了：
- 微服务粒度的上界是一个 2 Pizza Team 能够在一个研发周期内完成的全部需求范围。
- 微服务粒度的下界是它至少应满足:
2.1 独立——能够独立发布、独立部署、独立运行与独立测试，
2.2 内聚——强相关的功能与数据在同一个服务中处理，
2.3 完备——一个服务包含至少一项业务实体与对应的完整操作。
3.3 微服务需要的条件
这一个对于笔者而言就更显得实用了。
一直在传统软件行业里进行职业生涯，我见证了微服务如何在行业内一步步火热起来的，也见证了整个团队里每个人怀揣各自的心思，不断要求赶紧升级微服务架构，然后搞得各方怨声载道。为此笔者专门写下过一篇短文 —— 微服务了个寂寞。
本书中作者在Martin Fowler 的《Microservice Prerequisites》基础上，更进一步细化和与时俱进地提出了四个条件：
- 微服务化的第一个前提条件是决策者与执行者都能意识到康威定律在软件设计中的关键作用。
- 微服务化的第二个前提条件是组织中具备一些对微服务有充分理解、有一定实践经验的技术专家。
- 微服务化的第三个前提条件是系统应具有以自治为目标的自动化与监控度量能力。
- 微服务化的第四个前提条件是复杂性已经成为制约生产力的主要矛盾。
并且作者在给出这四个条件，并详细解释之后，用了“主动犯错”一词来阐明现实的无奈：
如果你不理解“主动犯错”，笔者可以举个具体例子，试想你就是一名架构师，项目立项中坚持要选择单体架构，此时你就要考虑到日后评审时，别的团队说他的产品采用了微服务，架构上比你的先进；考虑到招聘人员时，程序员听见你这里连微服务都没用，觉得制约了自己的发展前景；考虑到项目成功火爆了，几个月后你再提出进行微服务化，老板听了心里觉得你水平的确不行，之前采用单体是错误决定，导致现在要返工……
3.4 理解系统复杂性
本书总关于这一部分，对于不论是一个软件团队，还是个人职业发展都是有着非常深刻的指导意义。
笔者就亲眼见证了不少个人以及团队，总是以现有架构太烂，认为只要给我们一个机会推倒从来，那么现在这些问题都将不再是问题，关于这个想法的幼稚，一再重复的现实予以了验证，诸多著作中也给与了明确的反对，例如Bob大叔在《匠艺整洁之道》所表述的 —— "我们所需要的是稳定的生产力"。
笔者用以下两个心理学概念来解释复杂性的来源，受到较多开发者的认可：
4. 一些联想
- 得益于作者的博学和叙事方式。对于诸如容器网络，零信任网络等终于有了一个比较清晰的认识。而这给我的一大感受是：对于不甚料及的知识，尤其是行业内的，如果最初无法理解，那就强行先看下去，先有个印象，等未来再接触几次，让不同人用不同的视角给你解释这个概念后，你慢慢会明白的。尽早开始这个过程，不要因为不懂而选择拒绝了解。
- 作者在程序员之路中，不出意外地也谈到了舒适区，对于这个概念笔者并不陌生，但作者所表达的观点对于笔者却是有点戳中痛处的感觉，笔者过往一直在打造爱好阅读的人设，但最近两年慢慢发现，自己可能也是陷入了一种舒适区 —— 所谓的爱好阅读，更多的是行业内的书籍，相较之下，《毛选》第一卷看了一年多，两百多页的《技术的本质》也看了两年。这.....，不像爱好阅读的样子啊。
5. 推荐阅读本书
如果你能够看到这里，依然无法下定决心是否阅读该书，那么推荐你看下作者的这一篇程序员之路，从中你会感受到作者的赤子之心。
一本迭代三年，至今保持更新；并且主动提供离线版本，提供相关实际代码演示，且一直都不曾设想金钱方面的回报。试问这样的人，诸君见过多少？
网友评论