【架构设计】| 总结/Edison Zhou

在各种面试场合，可能都会被问到“你对架构设计的理解”，我也在最近的转正答辩中被技术委员会负责人问到，这里我重新整理一下思绪，聊聊我心中的的架构设计观。

1系统的本质是什么？

作为一个技术人，恐怕会被经常问到系统架构设计的问题，即便是刚刚毕业的应届生，可能也对6大设计原则 和 23种设计模式 了然于胸（虽然可能是感性认识较多）。

自认为自己还不算一名合格的系统架构师，但是对于系统架构设计的理解也在不断的深入，今天斗胆聊聊我心中的系统架构设计观。

要聊架构设计，就得先理解什么是系统？又或者说系统的本质是什么？

系统其实是由多个要素 及 连接关系 组成的共同体，它不仅局限于我们所熟悉的IT系统，它更是我们现实生活中的各种模型。但是，现实中我们往往首先看到的是要素，但是我们真正需要的修炼的是透过表现看清要素及其连接关系。

举个例子，就拿一只表来说，可能一般的人只会观察其中的表象即时针，秒针与表盘，但是有洞察力的人却会透过表象去看其中的成百上千个零件要素及其连接关系，最终得到一个钟表系统的模型。

系统论总结了要素之间的连接关系大致有这几种：因果链、增强回路、调节回路 及 滞后效应。在这几种关系中，最重要的就是 增强回路。

例如，润总在《商业洞察力》中举了一个例子，微软食堂（不得不说，别人家的公司就是好，还有这么好的食堂）。微软员工对于微软食堂的口味厌倦了，但是供应商的动力却不大，因此存在一条如下图所示的调节回路。微软人力部想到的办法是改变系统模型，所谓改变系统模型就是就是改变系统中的结构模块之间的关系，让结果自己发生。因此，微软选了两家供应商，一家提供午餐，一家提供晚餐，每个季度员工评价是喜欢午餐还是晚餐，如果喜欢晚饭多，那么午餐和晚餐的供应商进行交换（要知道，做午餐比作晚餐利润多）。如果连续两个季度即半年午餐都胜出，那么更换晚餐供应商。可以看出，这个模型采用了竞争的机制，类似于“鲶鱼效应”让微软食堂又焕发生机，成为了员工的最爱。从源头来看，这是因为在调节回路的基础上，改变系统模型增加了一条增强回路，从而激发了供应商的积极性。

一个好的系统（或模型），往往同时具有以上几种关系，但都具有较为稳定的增强回路，在推动着增长的飞轮持续前进。

2架构设计核心认知

有了对系统的基础认知，架构设计也就不难理解了，它们是类似的。

抽象地来看，架构也是由元素 和 关系组成的。

在架构设计中，较为稳定的、可复用的部分 会变成组件（Component）或 应用模块（Module），对应着架构中的元素。

元素对应着确定性内容的处理，是看待这个世界的稳定视角；

在架构设计中，对模块或服务的拆分，是考验一个架构师的基本功，毕竟分而治之是降低复杂度的基本方法。但是，元素并不是拆分得越细越好，3个模块能搞定的功能，非要写10个模块的过度设计，只能是给当前阶段的发布计划添乱。

而那些面向不确定性的设计，则会变成协作方式，为可能的扩展做准备，这对应着架构中的关系。

关系对应着不确定性内容的处理，是看待这个世界的响应视角；

稳定的关系，在架构中一般会用SOA、微服务架构来表示，做好服务调用即可；而不稳定的关系，则在架构中会会用EDA（事件驱动架构）来表示，做好异步处理（如发布订阅、最终一致性等）即可。

3好的架构设计

抽象来看，好的架构设计跟优秀的组织协作一样，既能帮助IT系统做好各模块的专业分工，又能体现模块间的协作精神。

从工程师到架构师，有一种能力是需要不断提升的，那就是对复杂业务的拆分能力、对可复用部分的抽象能力、对拆分过程的颗粒度把握，以及对未来变化的考量和设计。

如何让架构有足够的“应变和适应能力”，则与架构师对业务的理解程度息息相关。

基于上面对架构设计的认知，我们或许可以这样认为，对架构层面的【专业分工】和【协作精神】的理解，是架构师的基础与核心的能力。

我们可以从近几年火热的微服务架构 和 企业中台架构来理解：

微服务架构

我们都知道，在微服务架构中，每个服务的功能和数据处理是封装在一起的（和SOA类似），服务治理、监控、调用 等基础设施能力已经被封装在了框架（如Spring Cloud）中使得开发团队可以足够聚焦业务实现。

可以看到在微服务体系下，微服务开发框架、K8s、Service Mesh、Multi Runtime的出现，技术架构部分中的很多职责已经被抽象出来，它们都在体现着一个基本的原则：让系统的分工更明确、责任更清晰。

人类的理解能力有限。内容包含过多的元素，会导致理解困难，需要将其拆分；

有了专业的分工，也就是催生了服务的拆分，通常业界流行且认可的方法论就是DDD（领域驱动设计），通过划分 核心域、通用域 与 支撑域，为微服务的拆分提供理论指导。

企业中台架构

在一定时期内，一个企业的技术架构的功能或组件基本是稳定的，但是业务的运转却是动态变化的。因此，企业中台架构又被搬上舞台，它往往被赋予了快速响应市场变化的使命，其关键词包括了：架构解耦、消除烟囱、能力复用...

中台架构强调“企业级能力复用”，从架构的视角来看，它突出了“可重复部分的抽象”，阿里巴巴对组织结构调整，将职能型组织调整为可复用产品型组织—共享服务中心，建设微服务中台为前台业务提供快速接入的可复用能力。可以看到，它改变的是组织关系，映射到系统层面，它也体现着协作精神。

4康威定律

说完微服务架构 和 企业中台架构，我们再来看看在半个世纪前的一篇文章，它就是康威定律。

在康威的这篇文章中，最有名的一句话就是：

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)

中文直译大概的意思就是：设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。

看看下面的图片，再想想Apple的产品、微软的产品设计，就能形象生动的理解这句话。

用通俗的说法就是：组织形式等同系统设计。

一个系统的设计，其实也体现着团队的组织形式。小而美的团队注定比大而全的团队的沟通效率要高，做事效率要快。

换句话说，你想要什么样的系统，就搭建什么样的团队。如果你的团队分成前端团队，.NET/Java后端开发团队，DBA团队，运维团队，你的系统就会长成下面的样子：

相反，如果你的系统是按照业务边界划分的，大家按照一个业务目标去把自己的模块做出小系统，小产品的话，你的大系统就会长成下面的样子，即微服务的架构。

因此，按业务来划分团队，能让团队自然的自治内聚，明确的业务边界会减少和外部的沟通成本，每个小团队都对自己的模块的整个生命周期负责，没有边界不清，没有无效的扯皮。

此外，亚马逊的Bezos有个逗趣的比喻，如果2个披萨不够一个团队吃的，那么这个团队就太大了。事实上一般一个互联网公司小产品的团队差不多就是7人左右。

可以看到，康威定律所表述的基本原则也是元素及其连接关系，专业分工与协作精神，而这一切的出发点，都是为了降低成本 和 提高效益 以适应不断变化的市场环境。

End总结

人类在解决很多复杂问题时，都会采用类似的思维流程：将复杂问题拆解为简单问题，逐一解决再合并，并将可复用的知识抽象，以实现举一反三。

从抽象来看，架构设计的本质在于解决元素及其之间的连接关系，朝着专业分工和协作精神的方向不断演进，最终实现企业的降本增效的目的。

年终总结：Edison的2020年终总结

数字化转型：我在传统企业做数字化转型

C#刷题：C#刷剑指Offer算法题系列文章目录

.NET面试：.NET开发面试知识体系

.NET大会：2020年中国.NET开发者大会PDF资料

????扫码关注EdisonTalk

‍

‍‍

‍