什么是好的架构师

架构的本质
物理学中有个很著名的“熵增定律”：一个封闭系统，都是从有序到无序，也就是它的熵（即混乱程度）会不断地增加，最终系统会彻底变得无序。这个理论放在软件系统的演化上，也是非常适用的。一方面，随着业务需求的增加，我们会往系统里不停地添加业务功能；另一方面，随着访问量的不断增加，我们会不断通过技术手段来加强系统非业务性功能。如果事先不做良好的设计，随着时间的推进，整个系统野蛮生长，就会逐渐碎片化，越来越无序，最终被推倒重来。

这一点笔者很有体会，当你的编程技术能力远大于能实现的功能后，会考虑代码的优化和性能，而有时需求的叠加和不会预先告知以及需求的紧迫性会造成代码的混乱。

不过，自然界中的生物可以通过和外界交互，主动进行新陈代谢，制造“负熵”，也就是降低混乱程度，来保证自身的有序性，继续生存。比如，植物通过光合作用，把光能、二氧化碳和水合成有机物，以此滋养自己，延续生命。对于软件系统，我们也可以主动地调整系统各个部分的关系，保证系统整体的有序性，来更好地适应不断增长的业务和技术变化。这种系统内部关系的调整就是通过架构实现的，所以，架构的本质就是：

通过合理的内部编排，保证系统高度有序，能够不断扩展，满足业务和技术的变化。

首先，架构的出发点是业务和技术在不断复杂化，引起系统混乱，需要通过架构来保证有序。

软件系统也是如此，从简单的桌面应用发展到现在的大型互联网平台，这个过程中，系统规模越来越大，业务和技术也越来越复杂。我们同样需要通过架构设计，消化复杂性带来的混乱，使系统始终处于一个有序状态，能够应对现有和将来的需求变化。

其次，架构实现从无序到有序，是通过合理的内部编排实现的，基本的手段，就是“分”与“合”，先把系统打散，然后将它们重新组合，形成更合理的关系。

具体地说，“分”就是把系统拆分为各个子系统、模块、组件。拆分的时候，首先要解决每个部分的定位问题，然后根据定位，划分彼此的边界，最后实现合理的拆分，我们比较熟悉的微服务架构，就是一种典型的拆分做法。

“合”就是基于业务流程和技术手段，把各个组件有机整合在一起。比如说在微服务架构中，拆分为具体微服务后，我们需要对这些服务进行归类和分层，有些属于底层基础服务，有些属于上层聚合服务，还要尽可能地实现服务的平台化，比如我们最近说的中台，这些都是合的思想体现。

这个分与合的过程将系统的复杂性分解为两个层次：首先，各个子系统承担独立的职责，内部包含了自身的复杂性。子系统的复杂性对外部是透明的，外部不用关心。其次，子系统通过封装后，简化为职责明确的一个点，因此，我们只需要在合的过程中，解决各个点之间的依赖关系，这样就可以定义出系统整体。

举个例子，我们都知道 GoF 的 23 个设计模式，在 Builder 模式中，它的主逻辑只需要给出各个部件的组装关系即可，它不关心创建某个具体部件的内部逻辑，这个可以交给工厂模式去实现。这里，Builder 模式负责粗粒度的组装逻辑，它承担的是合的部分；工厂模式负责细粒度的构造逻辑，承担的是分的部分，大家各自管理自己的复杂性。

通过合理的“分”与“合”，系统不是回到了原点，而是把原先铁板一块的系统变成一个富有弹性的结构化系统。这样，系统的复杂性有效地分解了，系统的有序度大幅度地提升了。

架构的分类
按照不同的角度，架构可以有很多分类，但一般来说，主要分为业务架构、应用架构和技术架构。那么，这些架构分别为谁服务，解决什么问题，相互之间是什么关系呢？