阅读 865

我不服!这开源项目居然才888个星!?

你好呀,我是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/methodology/forward-msa/prerequest.html

问题如下:

周大哥,看到了您说的马太效应。再联想到之前您讲的软件涅槃,而完善的微服务体系允许服务有涅槃的过程,有强大的容错能力。微服务发展又如此迅猛,觉得马太效应真的不远。

我不禁对最需要掌握的技能进行了思考,并产生了更强的焦虑感。

我是一名有七年工作经验的java开发工程师,28岁,目前在一家北京的传统信息软件技术公司,工资相对计算机行业偏低。

局限在java语言来说,jvm调优与并发编程等比较高阶的能力,是不是就很不关键了?

jvm我读了您写的《深入理解Java虚拟机:JVM高级特性与最佳实践》的第二版与第三版,由于工作中鲜有机会实践,只停留在一些理论理解,而缺失实践,理论知识也会淡忘。

并发编程读过《Java并发编程实战》,对并发编程有些了解,也有一些实践,一般水平。

微服务公司并没有用起来,实践经验也缺少。远程调用、分布式事务、注册中心、配置中心、熔断、限流等知识,通过看视频跟您的这个文档有一些了解。

java基础知识,经过这些年的磨练,是挺扎实了,spring能熟练使用。

常用设计模式有了解,也理解的比较到位。

我不想沦为螺丝钉。

我应该提升自己的哪些能力呢?

这些年只是做到了胜任分配给自己的工作。

现在发现自己缺少前瞻性思考,缺少对自己职业生涯的把控。

我现在想把握自己的职业生涯,请周大哥给一些指导。

我会通过招聘市场去挖掘市场需求,做整理,进行思考。

但是迫不及待的想跟您述说一下,请您不吝赐教,希望我的请求不是很唐突。

这个问题其实是很具有普遍性的:学了没地方实践,慢慢就忘记了。理论学了一大堆,聊起来可以谈笑风生,但是就是没有实际使用过。自己就是一颗螺丝钉。

周佬的回复如下:

写这文章不是为了贩卖焦虑,我也没有能力指导别人的职业生涯,但针对“应该提升自己的哪些能力”这类问题,我以前被问过很多次,这里可以重复一下。

我的建议就两个:

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

为了便于你理解,我做一个很土的比喻,把程序员提升自己类比成武侠中的练功,软件中的技能其实有很明显的“内力”和“武功”之分,譬如你提到的Java虚拟机,这类知识不仅是你在工作中鲜有机会实践,我也是差不多的。

大学计算机课程中,以“原理”二字结尾的课程,譬如计算机原理、操作系统原理、编译原理、数据库原理,等等,对绝大多数人而言,都不太会去设计处理器逻辑电路、设计程序语言和编译器,开发操作系统内核。

这些都有很经典的书:编译原理的龙书,计算机体系结构和程序运行的CSAPP,分布式与数据库原理的DDIA、操作系统原理的MOS,等等。这些书系统严谨全面,但可读性并不优秀,在B站/Coursera刷这些书作者们的公开课翻译视频也许是更好的方法。

这些技能能够辅助你去思考和分析问题,但是很难直接为你解决生产中的问题,以实践价值,就是以工作中是否有机会用到来衡量它们的作用是不合适的。

但这些课程之所以会是必修,是因为学习它们,能够为一名程序员的知识框架构筑好基础。

这话听起来很教条,可是当你一旦建立了相对完备稳固的知识框架,发现遇到的新知识、新技术,能够很自然地安放在已有知识体系的某个位置上,能够清楚感知到语言、技术、框架的设计意图和目标,甚至能共鸣到设计者当时所想,就会产生一种理所当然的感觉。

这样你接受新知识的认知负荷就会比别人更低,掌握起来更快速,理解起来更深刻。

我在这文档开篇中所说的,写这部文档是以整理自己的知识框架为目的,并非场面话,这点的确就是程序员如何学习新知识的关键,在知识快速迭代IT业界,这也是决定一名程序员能力上限有多高的根本因素。

相对的,那些具体的、用来解决生产中问题的技术和方法,譬如你提到的Spring、设计模式,我将其类比为“武功”。

这当然也是重要的,只有内力没有武功无法行走江湖,空有一身理论,但写不出代码来(包括那些只定大方向的架构师、设计者),我认为不肯定是合格的程序员,也很难指望能成为一名出色的技术领导(难以服众)。

但是具体的“武功”应该是能够快速捡起的,也能快速“忘掉”的,就是避免将一件事情做熟了,就一直陷在这件事情里面,避免拿到一把好的锤子,就看着一切问题都像是钉子。

很多程序员都抱怨,自己是CRUD Boy,自己在业务逻辑中打滚,没有机会接触底层的或者前瞻性的技术,所以自己技术难以提升。

这里当然有客观原因的存在,但往往也是受到了主观原因放大。

程序员其实与旧时代的手工技艺者差不多,骨子里就有天生的技术崇拜,你写的代码比别人的优雅健壮高性能,你杀BUG比别人快速干净利索,就会受到大家的认可。

很自然地,更多偏向技术偏向深层次的工作就会落到你这里,至少你会有话语权,有选择做哪些事情的权利,是否要一直在围绕着你最熟悉的业务去打滚是由你决定的。

学习武艺成为“武林高手”,是成为大BOSS之后才不必长期面对虾兵蟹将的纠缠。

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

最后还有个追问和回答如下:

不知道大家看到这个回答后的感受是怎么样的。

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

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

已经放入手机标签中,时常提醒自己。

与君共勉。

文章分类
后端
文章标签