我不服！这开源项目竟然才888个星！？

你好呀，我是why。html

是的，我又发现了一个宝藏，又火烧眉毛的想分享给你们。java

这个宝藏是一个开源项目，或者叫作一本开源的书。程序员

让我意难平的是，这本写的如此具备学习潜力和指导意义的开源书，目前才 887 个 Star。算法

赶得早不如赶得巧，我就是第 888 个点 Star 的人，听起来就颇有缘分的样子：spring

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以后才没必要长期面对虾兵蟹将的纠缠。

学习一门具体的技术，也是为了用它解决好问题，而后把它忘掉，去掌握那些更深层次的、更前沿，并且本身还不会的技术。

最后还有个追问和回答以下：

不知道你们看到这个回答后的感觉是怎么样的。

至少对我而言，振聋发聩。特别是这两点：

• 不要轻视不直接产生实践价值的知识；
• 不要对陷入已经被你熟练掌握的技术中不能自拔。

已经放入手机标签中，时常提醒本身。

与君共勉。