架构 | 聊聊我心中的架构设计观

Posted 2021-09-07 dotNET跨平台

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了架构 | 聊聊我心中的架构设计观相关的知识，希望对你有一定的参考价值。

【架构设计】| 总结/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的产品、微软的产品设计，就能形象生动的理解这句话。