从架构设计到架构师

一、架构的定义

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

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

————摘自《百度百科》

二、架构是做什么？

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

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

新上一个系统，往往不是独立存在的，一般都需要与现存的系统进行交互，而需要集成交互的地方可能还很多，哪些集成是本系统需要实现的？同时，一般会划分为多个阶段开发，怎样界定系统的边界呢？

软件系统是一个由多个模块组成的整体。因此当上游开发与我们负责的模块衔接老是出问题时，自己再做更多的努力也无法扭转上游模块的质量差带来的负面效果。（我想大家这时候肯定是抓狂的。）

每次看到别人写的代码，老觉得自己来写的话肯定不会这么写。比他写的更好。（我们做技术的，自我感觉良好是个常态。）

在某些场景下，自己脑子里有多套方案来实现，但是对孰优孰劣没太大感觉，最终基本上就是拍脑袋选了一个。

某块代码维护的次数多了，特别是中间由多个人接手过后，代码风格各异，难以理解。

相似的代码在好几个地方出现，特别是一些非业务性的代码，比如日志处理等。再甚是在大型的分布式系统中，不同子程序使用了不同的同类型中间件，同样导致维护成本大增。

在2个相依赖项目边界处的设计产生了分歧，并且站在各自的角度看都有道理。

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

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

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

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

三、做架构的最佳实践

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

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

整个过程的主要目的是：

描述其与外部实体（系统和最终用户）的交互。

标识系统和外部实体间的信息和控制流。