你好呀，我是 why。
是的，我又发现了一个宝藏，又急不可待的想分享给大家。
这个宝藏是一个开源我的项目，或者叫做一本开源的书。
让我意难平的是，这本写的如此具备学习后劲和指导意义的开源书，目前才 887 个 Star。
赶得早不如赶得巧，我就是第 888 个点 Star 的人，听起来就很有缘分的样子：
https://icyfenix.cn/
先看一下我看了之后整顿的思维导图吧：
看不清没关系，文末会给你支付链接的。
看完之后我集体的一个感触是：
对于分布式架构方向，写的很多很全。而且都是笔者一路走过去的经验之谈，稀释在了文章外面。
对的起首页的这一句口号：构建牢靠的大型分布式系统。
谁写的？
那么这个开源书的作者是谁呢？
周志明。
是的，就是你想到的那个写了 JVM 的书的男人。
其实你认真看周佬写的自我介绍，很有小细节。
程序员、研究员、作者、布道师这四个职业，排在第一的是最没有噱头的“程序员”一职。
而在程序员外面，给本人的形容是：
一名兼职一些治理与钻研工作的程序员。
其实对于这个点，我看过周佬的一些公开场合的自我介绍，都是说本人是一个“兼职一些管理工作的程序员”，给本人这样的人设标签。
他在本人写的《程序员之路》一文中解释过这个标签。
他想要透过这个标签表白的是对于一枚程序员，当前是想要倒退为一个架构师还是研发管理者，都不要轻易地来到技术畛域的一线前沿，来到技术、放弃编码的决定很可能会像你高考之后放下的数学、生物、天文等常识那样，一旦撒手，毕生就很难有机会再从新捡起来。
当你放下代码的工夫越长，长此以往，你对代码、技术、产品状态与团队研发状态的了解，慢慢的会和团队成员产生了偏差错位，丢失了细节上给予领导的能力，丢失了业余问题上提出接地气解决方案的能力，只能在无奈短期难以校验对错的大策略方向提意见。
在会议、流程及团队治理措施上下功夫，在职业经理人式的宣讲与汇报上寻找存在感。
此刻，你便从团队的导师变成了管理者，最终你与团队的关系，从携手并肩奋斗的搭档，齐全演变成只能靠公司制度与治理职位的势力来维系雇佣关系。
我能了解周佬说的景象，其实是一个十分广泛的景象。甚至有的敌人走上治理岗位的指标就是不再写代码了，基于以后的市场和行业现状，这样的抉择是无可非议的。
只是，有没有那么一点点可能，不要齐全摈弃代码。这也须要是你和团队之间的最卓有成效的纽带。
就像《代码整洁之道》一书中说的：
软件架构师自身就是最好的程序员，他们会始终编写代码，尽管可能不会像其余程序员输入的代码量那样多，然而只有继续地编程，能力确保他们遇见其余程序员所面对的问题，领会其余程序员心中的感触，因而如果不编程，他们亦将无奈胜任软件架构这项工作。
这本《凤凰架构》，周佬本人对它的定位是这样的：
给开发人员整顿的对于软件架构方面的技能地图，同时零碎的梳理本人的常识，并装备了对应技术计划的演示程序。
真的是一件利人利己的事件。
我原本的想法是先带着大家囫囵吞枣的走一圈这一本书，次要起到一个介绍的作用。
然而越写越不得劲的感觉。因为即便我写的这么卖命认真，都没有体现出这本书的价值的千分之一。
你得本人去读，你才晓得我没有骗你：
这真的是个宝藏啊！
所以我决定换个思路，通知大家这外面有什么就行了，其实就是书中的摸索起步一大节。
摸索起步
这是摸索起步的更新日志局部，能够看到周佬对于该我的项目始终在进行保护新内容：
而对于已有的内容，其中的错别字、不通顺的中央、含意不清的中央，他也在抽时间批改，最近的一次批改就是 6 月 6 日，昨天，上周日：
所以，相比于其余的大部分网上的文章来说，会更加实时、零碎、优质一点。
全书分为五大部分和两个篇外，而为了让你疾速定位到适合本人的局部，周佬也仔细的介绍了每一部分对应的读者类型。
- 疏导篇 摸索起步: 这部分面向于筹备对文档介绍的内容亲自实际的探索者。
- 第一局部 演进中的架构：这部分适宜所有开发者，但尤其举荐刚刚从单体架构向微服务架构转型的开发者去浏览。
- 第二局部 架构师的视角：这部分探讨与格调无关的架构常识，适宜所有技术架构师、零碎设计、开发人员。
- 第三局部 分布式的基石：这部分面向于应用分布式架构的开发人员。
- 第四局部 不可变基础设施：这部分面向于基础设施运维人员、技术平台的开发者。
- 第五局部 技术方法论：这部分面向于在企业中能对重要技术决策进行拍板的决策者。
- 篇外 随笔文章：这部分无特定读者对象，内容是笔者日常文章的整顿。
- 篇外 附录：这部分面向刚开始接触云原生环境的设计者、开发者。
其中第一局部的我读完之后做的思维导图如下：
能够大家对于其中的后微服务时代和无服务时代略微有点生疏，然而我换个英文名称，大家就应该是十分相熟了。
后微服务时代其实就是云原生时代，Cloud Native。
而无服务其实就是 Serverless。
然而须要留神的是，周佬把 Serverless 排在了 Cloud Native 之后，其实它们两者并没有继承代替关系。不要因为周老对于两者的书写程序产生了“无服务就会比微服务更加先进”的错误想法。
周佬对于这两者之间的关系形容是这样的：
- 如果说微服务架构是分布式系统这条路以后所能做到的极致，那无服务架构，兴许就是“不分布式”的云端零碎这条路的终点。
第二局部的思维导图如下：
这一部分次要聊了咱们做分布式服务时，肯定会波及到的问题，比方：近程服务调用（RPC）、分布式事务的解决、多级分流、架构平安。
我集体认为这一部分是干货满满的。
其中拜访近程服务，对 RPC 和 REST 从各自的起源开始进行了一个详尽的形容：
事务处理大节，大家能够看看“共享事务”的概念，其实我发现有一部分号称是微服务架构的我的项目，走向了“共享事务”的路线。
我认为这是一种伪分布式。
通明多级分流零碎从客户端到网络在到服务端的拆析，这是一种上帝视角的形容，而这一部分的主题就是“架构师的视角”。
架构师就应该是从这样的一个比拟统筹规划的角度去对待零碎，不用进入到具体零碎的细枝末节中去：
第三局部分布式的基石：
共识算法、服务发现、流量治理、网络通信、监控预警独特形成了分布式的基石。
能够说如果是一个分布式的服务，都能找到下面的这些关键词的影子。
有些是利用零碎本人做的。
有些是开源框架就帮你搞定了，你甚至不晓得它们的存在。
然而下面的诸如流量治理和监控预警（可察看性）不是一个分布式服务一开始搭建时所必须的。
大多数状况下，刚刚搭建好的分布式都处于一个蛮荒状态。
随着工夫推动和业务的倒退，会缓缓补充上流量治理和监控预警。
也就是说如果想要分布式服务倒退的监控可控，那么这些货色都是应该有的。
“基石”一词，像是手术刀一样精准。
来到了第四局部，不可变基础设施：
到这里咱们就要从微服务走向云原生了。
在这一章，周佬以容器、编排零碎和服务网格的倒退为主线，介绍虚拟化容器与服务网格是如何含糊掉软件与硬件之间的界线，如何在基础设施与通信层面上帮忙微服务暗藏复杂性，解决本来只能由程序员通过软件编程来解决的分布式问题。
接下来的“技术方法论”属于微服务避坑指南，从目标、前提、边界、治理四个角度去论述如何更好的应用微服务。
最初一部分是“随笔文章”：
其中的《云原生时代，Java 的危与机》和《程序员之路》这两篇文章，倡议大家重复观看。
前者是技术方向的，后者是软技能方向的。
读完《Java 的危与机》，我感触到的是一场对于 Java 的自我反动曾经悄悄开始了。
Java 并不是一个优良的开发语言，这一点我是十分抵赖且确定的。然而 Java 有一个宏大的用户群体和异样丰盛的生态，这是它的护城河。所以短时间内还倒不下来。
然而大风起于青萍之末。风雨欲来，而包含我在内的很多人都浑然不知。
在文章外面，周佬有这样的一段话：
Java 反对提前编译最大的艰难在于它是一门动静链接的语言，它假如程序的代码空间是凋谢的（Open World），容许在程序的任何时候通过类加载器去加载新的类，作为程序的一部分运行。要进行提前编译，就必须放弃这部分动态性，假如程序的代码空间是关闭的（Closed World），所有要运行的代码都必须在编译期全副可知。这一点不仅仅影响到了类加载器的失常运作，除了无奈再动静加载外，反射（通过反射能够调用在编译期不可知的办法）、动静代理、字节码生成库（如 CGLib）等所有会运行时产生新代码的性能都不再可用，如果将这些根底能力间接抽离掉，Helloworld 还是能跑起来，但 Spring 必定跑不起来，Hibernate 也跑不起来，大部分的生产力工具都跑不起来，整个 Java 生态中绝大多数上层建筑都会轰然崩塌。
“整个 Java 生态中绝大多数上层建筑都会轰然崩塌。”
所以，Java 的这次改革属于要釜底抽薪。
读完《Java 的危与机》之后，你再去看《Graal VM》一文，你就明确了：为什么说 Graal VM 的胜利与否，与 Java 的前途命运非亲非故。
而这场改革未然轻轻开始，比如说一个小点：
大多数运行期对字节码的生成和批改操作，在 Graal VM 看来都是无奈承受的。
然而比方 CGLIB 就是通过运行时产生字节码（生成代理类的子类）来做动静代理的。
这是目前的支流模式。
当初因为 Graal VM 反对不了，所以必须由和框架一起来独特解决。
因而自 Spring Framework 5.2 起，@Configuration 注解中退出了一个新的 proxyBeanMethods 参数，设置为 false 则可防止 Spring 对与非接口类型的 Bean 进行代理。
同样地，对应在 Spring Boot 2.2 中，@SpringBootApplication 注解也减少了 proxyBeanMethods 参数，通常采纳 Graal VM 去构建的 Spring Boot 本地利用都须要设置该参数。
我最喜爱的还是技术演示工程局部，间接把我的项目 Demo 都给你筹备好了，开箱即用：
而且周佬写的这个开源我的项目有个特点，援用的局部会给出具体的官网的地址。谨严又权威，比方写到我的项目中用到的技术组件的时候：
一个问答
在我的项目外面，我还发现了一个问答。
问题和答复都十分的好，搬运过去给大家看看。
评论区：https://icyfenix.cn/methodolo…
问题如下：
周大哥，看到了您说的马太效应。再联想到之前您讲的软件涅槃，而欠缺的微服务体系容许服务有涅槃的过程，有弱小的容错能力。微服务倒退又如此迅猛，感觉马太效应真的不远。
我不禁对最须要把握的技能进行了思考，并产生了更强的焦虑感。
我是一名有七年工作教训的 java 开发工程师，28 岁，目前在一家北京的传统信息软件技术公司，工资绝对计算机行业偏低。
局限在 java 语言来说，jvm 调优与并发编程等比拟高阶的能力，是不是就很不要害了？
jvm 我读了您写的《深刻了解 Java 虚拟机：JVM 高级个性与最佳实际》的第二版与第三版，因为工作中鲜有机会实际，只停留在一些实践了解，而缺失实际，理论知识也会淡忘。
并发编程读过《Java 并发编程实战》，对并发编程有些理解，也有一些实际，个别程度。
微服务公司并没有用起来，实践经验也短少。近程调用、分布式事务、注册核心、配置核心、熔断、限流等常识，通过看视频跟您的这个文档有一些理解。
java 基础知识，通过这些年的磨难，是挺扎实了，spring 能纯熟应用。
罕用设计模式有理解，也了解的比拟到位。
我不想沦为螺丝钉。
我应该晋升本人的哪些能力呢？
这些年只是做到了胜任调配给本人的工作。
当初发现自己短少前瞻性思考，短少对本人职业生涯的把控。
我当初想把握本人的职业生涯，请周大哥给一些领导。
我会通过招聘市场去开掘市场需求，做整顿，进行思考。
然而急不可待的想跟您述说一下，请您不吝赐教，心愿我的申请不是很唐突。
这个问题其实是很具备普遍性的：学了没中央实际，缓缓就遗记了。实践学了一大堆，聊起来能够谈笑自若，然而就是没有理论应用过。本人就是一颗螺丝钉。
周佬的回复如下：
写这文章不是为了贩卖焦虑，我也没有能力领导他人的职业生涯，但针对“应该晋升本人的哪些能力”这类问题，我以前被问过很屡次，这里能够反复一下。
我的倡议就两个：
- 不要鄙视不间接产生实际价值的常识；
- 不要对陷入曾经被你熟练掌握的技术中不能自拔。
为了便于你了解，我做一个很土的比喻，把程序员晋升本人类比成武侠中的练功，软件中的技能其实有很显著的“内力”和“文治”之分，譬如你提到的 Java 虚拟机，这类常识不仅是你在工作中鲜有机会实际，我也是差不多的。
大学计算机课程中，以“原理”二字结尾的课程，譬如计算机原理、操作系统原理、编译原理、数据库原理，等等，对绝大多数人而言，都不太会去设计处理器逻辑电路、设计程序语言和编译器，开发操作系统内核。
这些都有很经典的书：编译原理的龙书，计算机体系结构和程序运行的 CSAPP，分布式与数据库原理的 DDIA、操作系统原理的 MOS，等等。这些书零碎谨严全面，但可读性并不优良，在 B 站 /Coursera 刷这些书作者们的公开课翻译视频兴许是更好的办法。
这些技能可能辅助你去思考和剖析问题，然而很难间接为你解决生产中的问题，以实际价值，就是以工作中是否有机会用到来掂量它们的作用是不适合的。
但这些课程之所以会是必修，是因为学习它们，可能为一名程序员的常识框架构筑好根底。
这话听起来很教条，可是当你一旦建设了绝对齐备巩固的常识框架，发现遇到的新常识、新技术，可能很天然地安放在已有常识体系的某个地位上，可能分明感知到语言、技术、框架的设计用意和指标，甚至能共鸣到设计者过后所想，就会产生一种天经地义的感觉。
这样你承受新常识的认知负荷就会比他人更低，把握起来更疾速，了解起来更粗浅。
我在这文档开篇中所说的，写这部文档是以整顿本人的常识框架为目标，并非场面话，这点确实就是程序员如何学习新常识的要害，在常识疾速迭代 IT 业界，这也是决定一名程序员能力下限有多高的基本因素。
绝对的，那些具体的、用来解决生产中问题的技术和办法，譬如你提到的 Spring、设计模式，我将其类比为“文治”。
这当然也是重要的，只有内力没有文治无奈行走江湖，空有一身实践，但写不出代码来（包含那些只定大方向的架构师、设计者），我认为不必定是合格的程序员，也很难指望能成为一名杰出的技术领导（难以服众）。
然而具体的“文治”应该是可能疾速捡起的，也能疾速“忘掉”的，就是防止将一件事件做熟了，就始终陷在这件事件外面，防止拿到一把好的锤子，就看着所有问题都像是钉子。
很多程序员都埋怨，本人是 CRUD Boy，本人在业务逻辑中打滚，没有机会接触底层的或者前瞻性的技术，所以本人技术难以晋升。
这里当然有客观原因的存在，但往往也是受到了主观原因放大。
程序员其实与旧时代的手工技能者差不多，骨子里就有天生的技术崇拜，你写的代码比他人的优雅强壮高性能，你杀 BUG 比他人疾速干净利索，就会受到大家的认可。
很天然地，更多偏差技术偏差深层次的工作就会落到你这里，至多你会有话语权，有抉择做哪些事件的权力，是否要始终在围绕着你最相熟的业务去打滚是由你决定的。
学习武艺成为“武林高手”，是成为大 BOSS 之后才不用长期面对虾兵蟹将的纠缠。
学习一门具体的技术，也是为了用它解决好问题，而后把它忘掉，去把握那些更深层次的、更前沿，而且本人还不会的技术。
最初还有个诘问和答复如下：
不晓得大家看到这个答复后的感触是怎么样的。
至多对我而言，发人深省。特地是这两点：
- 不要鄙视不间接产生实际价值的常识；
- 不要对陷入曾经被你熟练掌握的技术中不能自拔。
曾经放入手机标签中，时常揭示本人。
与君共勉。