聊聊架构设计做些什么来谈如何成为架构师

一、架构的定义

在软件开发领域，自从架构这个词被广泛传播之后，产生的架构模式也非常多，架构关注点也在增加。但回到“道”的层面，架构的定义或者说本质还是：

架构，又名软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。

——摘自《百度百科》

二、架构是做什么？

很多做业务功能的增删改查开发感受到无趣的小伙伴常把做架构想象成一片乐土，没有嘈杂的业务声音干扰，可以专心做一番牛X的技术。会把架构单纯的理解成，牛X的性能、牛X的TPS、高可用，支撑了多少PV等等。但是其实这些只是架构很小的一部分，并不是全部。在互联网时代之前都是C/S程序的天下，那个时候并没有对性能等有像现在这样的关注度，但是就已经有架构之说了。
世上本无架构，只是由于团队越大越需要对整体的规则做约定，好让大家往同一个方向发力，避免各自为战，产生大量的内耗，所以才逐渐形成了架构。这条路就是“世上本无路，只是因为走的人多了变成了路”。

为什么说一个软件架构是很重要的呢？当我们的团队人数只有2、3个人，甚至只有1个人单枪匹马的情况下，可能架构凸显的作用不是那么的明显，但是如果团队大了之后相信下面的这些现象会比较常见：

任何事物都是有两面性的，并不是说上面的这些问题，我们通过架构就要往另外一个极端去走。比如在大型的分布式系统中，不同子程序的确有必要在某些时刻选择同类型的其它中间件。如Kafka和RabbitMQ虽都是MQ，但在特定的场景下能发挥的价值是无法相互替代的。

所以我们做架构有一点也是比较重要的，就是去Balance，选择一个投入产出比最优的方案。关于这点第四段中会多说几句。

除此之外，架构的主要目的是为了让大家往同一个方向，在同一个标准之上去发散扩张。一是把控硬性的下限标准，提高整体的最短版，二是提高上限水平位，也就是天花板位置，提供更大的发展空间。好比造一幢大楼，把框架结构设计好搭好，让大家形成一个共识，什么是承重墙不能破坏，什么是创变空间可以自定义。在这样的基础下各自发展。这个看上去是个限制，但却是做架构最重要的任务，所谓再多的文档，再多的最佳实践都比不上一条约束。降低复杂度、降低理解难度，是实实在在的收益。最怕的就是凭空假设带来的过度浪费。

更甚之，我们做架构追求的理想国度是一个大家拥有一致共识的世界，架构是大家都像吃饭喝水这样习以为常的习惯。去理解或者接手其它人负责的项目的时候就好像是自己写的一样。这个时候就消灭架构了，就好比现在没有人会教你如何吃饭一样。（就当YY一下吧：）。）

三、做架构的最佳实践

上面提到更多的是做架构的目的，那么要做好架构，主要就是要做好抽象，做抽象的方式是类比，做类比的方式可以使用用例图。所以建议大家多画图，通过画图来将大脑中抽象的结果直观的体现在前面，再来进一步分析合理性。主要推荐2种图的类别，一种就是前面提到的用例图。如下图：

另外一种是鲁棒图，如图：

整个过程的主要目的是：

最后附一篇之前整理的《软件开发中会用到的图》的文章地址，有兴趣的同学可以扩展阅读下：https://www.cnblogs.com/Zachary-Fan/p/developdiagram.html。

理想的世界里，我们程序的边界设计恰好匹配于业务边界。然而我们作为工程师首先要承担业务需求的压力，只能挤时间去做这些非业务性工作。也因此老项目的业务边界也并不总是如新项目那样明晰。

这意味着做任何架构的改动要考虑优先级，特别在拆分业务领域之前认真地思考业务的边界。排定优先级，考量拆分的收益与风险。划分业务的边界，则需要更多的思考拆分后的未来将如何沟通协作，然后再考虑技术因素。在技术因素前，主要考量这几点：

 ●  如果曾经用过或者有其中一部分的经验可复用，这是加分项，毕竟在使用的过程中才发现hold不住它，那是灾难性的！

四、什么是好架构

之前有听到过一句话，概括的很精辟。好的架构必须需要贴合业务，那么把业务+技术演变成一个数学公式来表达可以理解为：2个数字的和等于10，求如何组合能得到最大的乘积。那不是37，也不是46，而是5*5。

所以架构不是生搬硬套，为了架构（搞事情）而架构，赶时髦，或者说装X。我们应避免通过个人的主观意愿来主导。比如自己觉得某个中间件好，就”拿着锤子到处找钉子“，这一敲下来，看着不错，但是带来的成本和风险被忽略了。可能有更好的解决方案，或者完全没必要在当下敲这一钉子下去。　　

好的架构需要评判投入产出比，收益更高的就是更好的架构，就如下图的公式。产出可以理解为我们因此获得的好处（诸如可靠性、安全性、可扩展性、可维护性、可伸缩性、性能等），成本是我们改造花费的投入，如人力物力和时间。特别注意的是风险这点，是很重要也是很容易被大家忽略的一点，是起到指数级作用的。选择的方案再好，如果都是一些hold不住的技术，那么风险就是无穷大，导致减号右侧无限趋近于0，最终的结果就是收益是负数，投入的成本打水漂，甚至还要加上其它额外的付出。

上面提到的这些关注点都是架构师的职责，另外特别重要的一点是，架构师必须要是个有追求的“好码农”！！！（划重点）。软件架构师不像建筑师，其面对的本身是一个抽象的事物，如果再脱离了实操，这基本和纸上谈兵无异。所以实际工作中的难点、要点都得清楚，并且能够给出解决方案或者方向。另外只有熟悉实操才能更准确的评估成本

成为了一个真正的“好码农”就向架构师迈出第一步了。而后呢，需要不断以深 → 广 → 深 → 广的节奏去开疆扩土，扩大自己的知识领域，当然需要以贴近当前工作内容的知识为主，这是第二步。到了这还没完，还有打造三板斧：业务能力、沟通能力、个人魅力。

题外话，在国内，纯技术的架构师没有应用型的架构师吃的开。所以此文皆以应用型架构师的职能要求为参考。

六、结语

回到文章开头，架构的表现形式有很多，从本质上单体应用的架构设计思想和分布式系统是一致的，所谓服务化其实也是模块化的思想，只是维度的不同，导致用到的一些工具或者环境不同，但这都是“术”层面的东西。光学这些招数，永远也学不完。架构之路漫长，继续前行，共勉。

原文发布时间为：2018-11-23

本文作者：Zachary_Fan

本文来自云栖社区合作伙伴“高效运维”，了解相关信息可以关注“高效运维”。