一周技术思考（第28期）-架构师，从象牙塔里走出来

大家好，这里记录，我每周读到的技术书籍、专栏、文章以及遇到的工作上的技术经历的思考，不见得都对，但开始思考总是好的。

架构师，从象牙塔里走出来

 

象牙塔这个词从百度百科上搜索其定义，有如下的介绍。

 

“象牙塔”一词后来被逐渐运用到社会生活的各方面，在汉语中，象牙塔本指忽视现实社会丑恶悲惨之生活，而自隐于其理想中美满之境地以从事创作的人，意为超脱现实社会，远离生活之外，躲进孤独舒适的个人小天地，凭借头脑从事写作活动的人；如今含义为“比喻脱离繁杂多变现实生活的知识分子（文学家和艺术家、科学家）的小天地，专心从事学术事业的人”，其被誉为“与世隔绝的‘梦幻境地’、逃避现实生活的‘世外桃源’、‘隐居之地’"。

 

读下来，总结一句话，有点偏离了实际。

 

在上一期的一周技术思考文章中，我提到了架构设计与实际代码脱离的问题，讲了墙上的架构图是一回事，工程代码又是一回事，它们之间失去了映射联系。

 

发出去之后，也收到了朋友的反馈。

 

 

 

现实中，确实存在着两种架构师，一种是象牙塔里面的架构师，一种是务实的架构师。

 

“框架必须永远使用springcloud！”

“所有的前端页面都应该使用Vue！”

“把过去，现在，将来一切的数据都要保存到elasticsearch中去！”

 

这是典型的象牙塔中的架构师在跟程序员沟通时候的表现，他们很享受那种绝对完美的最终状态，但软件的现实是动态变化的，而且还需要架构师积极地去不断思考这种动态变化，其更殊不知，一名架构师，首先要是一名优秀的程序员。

 

没心思倾听程序员心声的架构师，肯定也没心思听取用户的意见。

 

也就没有意识去真诚地关注软件的价值产出-软件产品。

 

务实的架构师，他们是怎么做的呢，他们是怎么思考问题方式是怎样的呢？

 

“如何在不修改原有代码逻辑的情况下，去增加新的代码文件来实现这次需求？”

“我们在监控线上系统运行情况的时候，需要收集哪些指标？”

“在收集了这些指标之后，我们如何对它们进行分析？”

“一段时间过后，系统中哪个功能代码模块最需要改进？”

 

务实的架构师，会一直保持动态变化的思维，会经常与程序员一起沟通交流问题，一起聊一聊现在的功能代码是否足以满足当前的请求负荷，以及，随着需求和请求量的双重增加，哪些功能组件需要替换。

 

 

蝴蝶图和蜘蛛图

 

你应该不曾想过，蝴蝶和蜘蛛会跟架构扯上关系，可它真的就出现了，就在《发布！设计与部署稳定的分布式系统》这本书里面。

 

为了能够让你看到这么生动而形象的架构比喻，在这里引用书中的三幅图来阐述下蝴蝶和蜘蛛，看完之后你会发觉它真的很妙。

 

架构蝴蝶图

 

 

架构蜘蛛图1

 

架构蜘蛛图2

 

 

 

当我们看这些图的时候，或者是我们在生产实际中自己画类似的架构图的时候，我们最关心的是什么呢。

 

关心每个节点模块的功能组成？

 

关心功能内部的技术实现？

 

还是关心模块之间的关系调用？

 

关心以上这些都没有问题，毕竟，我们一直再说，系统=模块+关系。

 

书中给了我们一个有意思的总结

 

新入行的架构师往往把重点放在方块上，而有经验的架构师则对箭头更感兴趣。

 

为什么有经验的架构师更关注箭头呢，箭头代表着关系，代表着通讯，代表着调用。因为分布式系环境下的系统，最大的不稳定性因素之一就是网络。

 

上面那三种风格的架构图，它们都有个共同的特点，就是连接数超过了服务数。也就是箭头超过了方块。蝴蝶图有2N个连接数，而蜘蛛网最多会有N的2次方个连接数。很显然架构蜘蛛图2是最不好的一种架构设计方式，这个图也是众多讲微服务内容里面的一个反例图。

 

从稳定性上来看，这样交错复杂的系统一旦出现”裂纹“，后果将会非常严重。

 

现实中，比如，墙上有个裂纹，这堵墙将来有可能整个裂开，一座水坝有个裂纹，这座大坝将来就可能决堤，正所谓“千里之堤，溃于蚁穴”。

 

系统中的“裂纹”，比如一个RPC请求的时间相应变长，在分布式系统里面，引起连锁反应之后，会导致“问题膨胀”，最终整个系统停止服务响应。

 

高度交互的复杂性和紧耦合这两个”幽灵“，会将快速动态变化的裂纹转变为彻底的系统事故。

 

什么情况下会导致交互复杂性？

 

当系统具有足够多的动态变化组件和隐藏的内部依赖关系时，高度交互的复杂性就产生了。

 

系统的紧耦合又是怎么产生的？

 

当应用程序的代码、系统间的调用或任何存在多个使用者共用同一资源的地方，紧耦合也就来了。

 

 

关于稳定性的内容，比如稳定性的反模式设计，以及正确处理稳定性的方式，更多的内容大家可以读一读这本书。

 

注：《发布！设计与部署稳定的分布式系统》这本书的内容质量和翻译质量都很高，值得一读。

 

 

“软件工程”这个名字的由来

 

也是这本书中发现的，直接贴张图吧，如果是真的，那确实是一件有意思的事情。

 

 

三条腿的板凳

 

这个小节，跟技术没有关系，但是跟学习有关，跟一个团队组织学习有关，如果我们学习的是技术，那其实也是有关系的。

 

我就放肆的说一说，身边学习的人，真的很少，在我的团队里面也是这样。我就一直在思考这个问题，也困扰了我很多年。

 

我再放肆一些的说，我是一个能够主动学习的人，但我为什么没有影响到身边的人呢，这个更是困扰了我很多年。

 

可能这周我发现了这个原因，我只是说可能，因为我还没有来得及实践。

 

这周翻了《第五项修炼》这本书，里面有一个“三条腿的板凳”的模型，如下图所示。

 

 

这样就明白了，激发一个团队的学习能力，跟激发一个人的学习能力是有很大区别的，首先你要激发出团队的热望，其次，你要开展反思性交流，最后大家还要通过理解复杂事物来提升系统思考的能力，而且是团队的能力。

 

大家，不妨也通过这三个步骤，在自己的团队中去实践几次，共同交流。

 

这是一个团队的提升，当然了，你可能会说，如果每个人的主动意识，主动学习的意识都很强，也就不会，浪费团队资源了，还要有系统来组织大家，来千方百计的为大家设计一个个的场合来学习。

 

我是很同意这种说法的，因为你有什么样的行为，就获得到什么样的反应。

 

 

 

 

反作用就像一面镜子，你的所作所为都会反射到你自己身上。

 

正因为，并不是每个人都有这样的主动性，所有，才有了组织性地进行组织学习活动。

 

记得，把《第五项修炼》里面的那张图，来练一练。

 

 

保持成长

 

来，一起问自己下面三个问题。

 

最近有失败的经历吗？

 

身边有人每天都对你形成挑战吗？

 

能说出上周你学到了哪些重要的东西吗？

 

如果你对上面的任何一个问题的回答都是否定的，那这可能是一个不详的信号。

 

作为一名技术人员，你身上始终有三要素，技术方向、保持成长，交付工作，其中保持成长是这三个要素中最重要的，也是你的原动力所在。

 

不进则退。

 

此图自己画的

 

 

恭喜你，又完成一次思考。

 

 

 

参考资料

《发布！设计与部署稳定的分布式系统》、《第五项修炼》、《软件架构师的12项修炼》文中配图均来自这三本书