关于java:我不服这开源项目居然才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/methodolo…

问题如下:

周大哥,看到了您说的马太效应。再联想到之前您讲的软件涅槃,而欠缺的微服务体系容许服务有涅槃的过程,有弱小的容错能力。微服务倒退又如此迅猛,感觉马太效应真的不远。

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

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

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

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

并发编程读过《Java并发编程实战》,对并发编程有些理解,也有一些实际,个别程度。

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

java基础知识,通过这些年的磨难,是挺扎实了,spring能纯熟应用。

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

我不想沦为螺丝钉。

我应该晋升本人的哪些能力呢?

这些年只是做到了胜任调配给本人的工作。

当初发现自己短少前瞻性思考,短少对本人职业生涯的把控。

我当初想把握本人的职业生涯,请周大哥给一些领导。

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

然而急不可待的想跟您述说一下,请您不吝赐教,心愿我的申请不是很唐突。

这个问题其实是很具备普遍性的:学了没中央实际,缓缓就遗记了。实践学了一大堆,聊起来能够谈笑自若,然而就是没有理论应用过。本人就是一颗螺丝钉。

周佬的回复如下:

写这文章不是为了贩卖焦虑,我也没有能力领导他人的职业生涯,但针对“应该晋升本人的哪些能力”这类问题,我以前被问过很屡次,这里能够反复一下。

我的倡议就两个:

  • 不要鄙视不间接产生实际价值的常识;
  • 不要对陷入曾经被你熟练掌握的技术中不能自拔。

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

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

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

这些技能可能辅助你去思考和剖析问题,然而很难间接为你解决生产中的问题,以实际价值,就是以工作中是否有机会用到来掂量它们的作用是不适合的。

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

这话听起来很教条,可是当你一旦建设了绝对齐备巩固的常识框架,发现遇到的新常识、新技术,可能很天然地安放在已有常识体系的某个地位上,可能分明感知到语言、技术、框架的设计用意和指标,甚至能共鸣到设计者过后所想,就会产生一种天经地义的感觉。

这样你承受新常识的认知负荷就会比他人更低,把握起来更疾速,了解起来更粗浅。

我在这文档开篇中所说的,写这部文档是以整顿本人的常识框架为目标,并非场面话,这点确实就是程序员如何学习新常识的要害,在常识疾速迭代IT业界,这也是决定一名程序员能力下限有多高的基本因素。

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

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

然而具体的“文治”应该是可能疾速捡起的,也能疾速“忘掉”的,就是防止将一件事件做熟了,就始终陷在这件事件外面,防止拿到一把好的锤子,就看着所有问题都像是钉子。

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

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

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

很天然地,更多偏差技术偏差深层次的工作就会落到你这里,至多你会有话语权,有抉择做哪些事件的权力,是否要始终在围绕着你最相熟的业务去打滚是由你决定的。

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

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

最初还有个诘问和答复如下:

不晓得大家看到这个答复后的感触是怎么样的。

至多对我而言,发人深省。特地是这两点:

  • 不要鄙视不间接产生实际价值的常识;
  • 不要对陷入曾经被你熟练掌握的技术中不能自拔。

曾经放入手机标签中,时常揭示本人。

与君共勉。

【腾讯云】云产品限时秒杀,爆款1核2G云服务器,首年99元

阿里云限时活动-2核2G-5M带宽-40-100G SSD服务器,特惠价86元/年(原价724元/年,限时99元续购三次),速抢

本文由乐趣区整理发布,转载请注明出处,谢谢。

You may also like...

发表评论

邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据