架构三要素：Business、operation and infrastructure！



架构师的由来

架构师并不是原生的IT专业名词，是一个舶来品。但用在IT行业，却异常的贴切。



在聊架构的要素之前，我想先聊聊架构这个词是怎么来的。"架构师"一词原本不是一个IT专业的词汇。Architect 原本指建筑师，也就是设计建筑物的人。以下来自维基百科：



建筑师通过与工程投资方和施工方的合作，在技术、经济、功能和造型上实现建筑物的营造。在逐步复杂的建筑营造领域，建筑师越来越多的扮演一种在建筑投资方和专业施工方之间的沟通角色，同时也对结构、水电、暖通进行总体协调。建筑师通常为建筑投资者所雇佣并对其负责，而不是建筑施工者。建筑师需要兼备艺术家的审美眼光和工程师的力学知识，作品需要从力学角度计算，选取合适的工程材料才能实现，如果过于超出现实的材料能力限制（例如市场供应、价格等），则无法实现为真实的建筑。建筑师的设计也必须能说服投资方的赞成，才能付诸实现。https://zh.wikipedia.org/zh-hans/建筑师



简而言之，建筑师就是绘制蓝图的人。这里的蓝图既要满足预算，又要满足艺术和功能的需求。同时，架构师也是沟通的桥梁，帮助项目从蓝图变为现实。那么整个IT系统越来越复杂的情况下，需要这么一个类似建筑师的角色：既能满足预算，又能满足艺术、功能等需求，同时也能衔接各个团队讲设计变为现实，所以IT的架构师就诞生了。



一栋建筑在设计之初，就需要考虑整个建筑的使用目的；如何去使用/维护；以及需要何种基础设施\材料来建造。和设计一栋房子非常类似，设计一个系统或者说是架构，也要有3个方面上的满足：功能；使用/维护；以及基础设施。我认为这就是IT 系统的架构三要素。没有这三个要素的架构，是不完整的，无法交付的。即使这三个要素都满足了，架构师也要具备说服项目干系人的能力。所以通常，架构师不是一个技术宅，而是有高超沟通能力的人。

架构三要素

架构的三个要素不是割裂的，而一个架构整体的三个面。相互制约也相互依赖。

功能/业务 (Business)

Business，这是一个高度抽象的概念，在不同的场景、层次下有不同的解释。



一个架构设计，首先要解决的一个特定的业务问题。也就是说，看一个架构是否合理，就是要看一个架构设计是否合理的匹配了特定的业务问题。这里的业务是一个高度抽象的名词。在不同的场景、层次下有不同的解释。打个比方，如果你负责一个微服务化的在线商城的日志中心的架构，那么你的业务就是如何多快好省的存储、查询日志(这很难)。但是在更高层次的整个商城架构中，日志中心只是一个组件。那么在更高的业务场景，或者集团场景下，商城也可能也是某一个组件。再往上拔高，到了企业架构的视角，就不再有具体的技术组件，而是只有组织和人。整个企业围绕某个业务，来设置组织结构和人。



所以架构师应该能在迅速的找到自己所在的层次，并且将自己的上下两个层次连接起来。故曰：承上启下。一个只知道闷头做技术的架构师，不是一个好架构师。一个好的架构师，永远要将自己的视角放到更高的层次，满足更高层次的业务需求。

使用/维护(Operation)

Operation我的理解不止是维护，而是使用 + 维护



很多人理解Operation 是维护的意思。我觉得可能仅仅维护是不完整的。所有的交互，包括使用是Operation。这是一个非常宽广的概念。一个系统在设计之初，应该考虑用户如何通过和系统的交互，来完成用户的业务目标。于此同时，也应该考虑到系统如何持续、安全的运转。就像设计一个歌剧院，首先要满足功能需求，要有演员化妆空间，演出大厅也要满足声学要求。然后还要考虑观众如何进场、安防、场馆日常维护等。这里渐渐从抽象的业务，过度到了具体如何使用。当然咱们在开头说了，如何使用/维护一个系统，除了和业务有关系，也和技术有关系，也就是下一节要聊的基础设施。架构的各个要素，互相约束也互相依赖。



在网上经常能看到各种各样的架构设计文章，但是这些架构设计里面通常不包含operation部分。最多包含如何使用部分。但脱离了维护，如何满足系统持续、稳定、安全的运转呢？



基础设施(Infrastructure)

人可以离开人体，以纯粹的精神形式存在吗？恐怕不能。



狭义的IT Infrastructure，是指操作系统之下的一层。包括虚拟化层、硬件、网络、操作系统等。我个人觉得在现代的技术潮流下，咱们可以将基础设施的概念进行进一步的扩展。抽象上的基础设施，可以包括一切支持业务使用、运维的组件。这些组件可能不只是硬件、软件、操作系统、framework，也可以是人。尤其是在容器化大行其道的当下，很多软件组件已经成为了Infrastructure 的一部分。无论软件还是硬件的基础设施，它们共同支撑了，也制约了系统的分功能性需求。也就是说，一个架构，需要明确其运行的环境、基础设施。如果没有基础设施部分，那么如何满足其非功能性需求是不明确的，也不是一个可落地的架构设计。最多算一个技术指导。



总结



咱们在开头说了，这三个要素并不是割裂的，而是互相依赖、互相制约的。如果一个系统是人，那么Infrastructure 相当于肉体，我们的肉体机能限制人体能力的天花板。跑的再快，也快不过阿尔伯特( 未来也许可以，但极限永远存在)。Business 相当于我们的理想目标。Operation 相当于我们的如何达成理想并且如何持续的活下去。这三要素缺一不可。

架构师的软技能



架构师不只是一个技术角色。架构师是一个综合性的角色。必要时，架构师可以有很多技术方面的帮手。但架构师应该是做决策的那个人，并且有能力说服大家同意这个决策。这里我引用一下我们CTO曾经说过的一句话：架构师不是一个title，而是一种能力。有了架构能力的人，就是架构师。

决策力 + 说服力

好的决策，天生就令人信服。



我个人觉得，技术只是架构师要求的表象。更深层次的要求是架构师必须要有自己明确的想法，并可以沿着自己的想法走下去。没人一出生就什么都会。但是有的人可以通过不断的观察和探索找到合适的路径。在这个过程中，去学习、去和各个干系人去碰撞。在这个过程中，想法不断的打磨，同时也能收获相关干系人的范阔。当有不同的意见的时候，架构是应当去分析这些不同意见的根本出发点在哪里，并酌情处理。酌情处理的意思是，必要的时候，架构师必须要坚持自己的决策。好的架构师，知道自己何时应该拍桌子。