每个架构师都应该研究下康威定律

- 日理万妓 2022-04-24 01:28 165阅读 0赞

# 背景 #

今天的分享主要来自我之前的工作经验以及平时的学习总结和思考。我之前的背景主要是做框架、系统和平台架构，之前的工作过的公司eBay、携程、唯品会都是平台型互联网公司，所以今天主要带着平台架构视角和大家分享心得体会。架构的视角每个人都不一样，可以说一万种眼光，有业务架构、安全架构、平台架构、数据架构，各不相同，这里仅是我的一家之言，欢迎大家加入『聊聊架构』社群参与讨论。今天聊的话题主要包括以下几点：

1.  我对架构定义的理解
2.  架构的迭代和演化性
3.  构建闭环反馈架构（Architecting for closed loop feedback）
4.  谈谈微服务架构和最新主题
5.  架构和组织文化关系
6.  架构师心态和软技能
7.  我对一些架构师争议主题的看法

# **我对架构定义的理解** #

大概在7~8年前，我曾经有一个美国对口的架构师mentor，他对我讲架构其实是发现利益相关者（stakeholder），然后解决他们的关注点（concerns），后来我读到一本书《软件系统架构:使用视点和视角与利益相关者合作》，里面提到的理念也是这样说：系统架构的目标是解决利益相关者的关注点。

![每个架构师都应该研究下康威定律][4a56a99eb9b14b6286441b775a11850d]

这是从那本书里头的一张截图，我之前公司分享架构定义常常用这张图，架构是这样定义的：

1.  每个系统都有一个架构
2.  架构由架构元素以及相互之间的关系构成
3.  系统是为了满足利益相关者（stakeholder）的需求要构建的
4.  利益相关者都有自己的关注点（concerns）
5.  架构由架构文档描述
6.  架构文档描述了一系列的架构视角
7.  每个视角都解决并且对应到利益相关者的关注点。

架构系统前，架构师的首要任务是尽最大可能找出所有利益相关者，业务方，产品经理，客户/用户，开发经理，工程师，项目经理，测试人员，运维人员，产品运营人员等等都有可能是利益相关者，架构师要充分和利益相关者沟通，深入理解他们的关注点和痛点，并出架构解决这些关注点。架构师常犯错误是漏掉重要的利益相关者，沟通不充分，都会造成架构有欠缺，不能满足利益相关者的需求。利益相关者的关注点是有可能冲突的，比如管理层（可管理性）vs技术方（性能），业务方（多快好省）vs 技术方（可靠稳定），这需要架构师去灵活平衡，如何平衡体现了架构师的水平和价值。

关于架构的第二点定义是说架构主要关注非功能性需求（non-functional requirements），即所谓的-abilities。

![每个架构师都应该研究下康威定律][f27dc92f86d24f9781bf952dd6fd252d]

这个是我上次公司内分享的一个图。

![每个架构师都应该研究下康威定律][5ccb4ddf64d64c80a28426fdae80f991]

这个是slideshare一个ppt里头截取的，两个图都是列出了架构的非功能性关注点；关于架构的水平该如何衡量，去年我看到一句话，对我影响很大。

Architecture represents the significant design decisions that shape a system, wheresignificant is measured by cost of change.

翻译为中文就是，架构表示对一个系统的成型起关键作用的设计决策，架构定系统基本就成型了，这里的关键性可以由变化的成本来决定。这句话是Grady Booch说的，他是UML的创始人之一。

进一步展开讲，架构的目标是用于管理复杂性、易变性和不确定性，以确保在长期的系统演化过程中，一部分架构的变化不会对架构的其它部分产生不必要的负面影响。这样做可以确保业务和研发效率的敏捷，让应用的易变部分能够频繁地变化，对应用的其它部分的影响尽可能地小。

我刚入软件开发这个行业之出，谈的架构主要是性能，高可用等等。现在，见过无数遗留系统，特别是国内企业IT的现状，无数耦合性系统的遗留系统，不良的架构象手铐一样牢牢地限制住业务，升级替换成本非常巨大， 所以我更加关注可理解，可维护性，可扩展性，成本 。我想补充一句，**创业公司创业之初获得好的架构师或技术CTO非常重要**。

# 架构的迭代和演化性 #

我是属于老一代的架构师，99年参加工作。职业初学了很多RUP，统一软件过程的理念。RUP的理念对我的架构有很深的影响，RUP总结起来就是三个特点：

1.  用例和风险驱动Use Case and risk driven
2.  架构中心Architecture centric
3.  迭代和增量Iterative and incremental

RUP很注重架构，提倡以架构和风险驱动，该开始一定要做端到端的原型prototype；通过压测验证架构可行性，然后在原型基础上持续迭代和增量式开发，开发->测试->调整架构->开发，循环，如下图所示：

![每个架构师都应该研究下康威定律][e50c96e9262c4bce8eb161afc214adc9]

从上图可以看出架构师要尽可能写代码，做测试，纸上谈兵式做架构而后丢给团队的作法非常不靠谱（除非是已经非常清晰成熟的领域）。另外，做技术架构的都有点完美主义倾向，一开始往往喜欢求大求全，忽视架构的演化和迭代性，这种倾向易造产品和用户之间不能形成有效快速的反馈，产品不满足最终用户需求，继续看下面两个图：

![每个架构师都应该研究下康威定律][e083eec724b644d2bfbd3cd135387c4b]

![每个架构师都应该研究下康威定律][44546828b87747f8bd880d4658a44103]

第一个图是讲最小可用产品（Minimum Viable Product， MVP）理念，做出最小可用产品，尽快丢给用户试用，快速获取客户反馈，在此基础上不断迭代和演化架构和产品。第二个图是过度工程（Over Engineering）的问题，其实也是讲产品架构和用户之间没有形成有效的反馈闭环，架构师想的和客户想的不在一个方向上，通过最小可用产品，快速迭代反馈的策略，可以避免这种问题。**注意，在系统真正地投入生产使用之前，再好的架构都只是假设，产品越晚被使用者使用，失败的成本和风险就越高，而小步行进，通过MVP快速实验，获取客户反馈，迭代演化产品，能有效地减少失败的成本和风险。**

另外，多年的经验告诉我，架构，平台不是买来的，也不是用一个开源就能获得的，也不是设计出来，而是长期演化才能落地生根的

给大家推荐两篇不错的微信文章（微信不能插入链接，根据题目Google下即可）：

1.  58同城沈剑：好的架构源于不停地衍变，而非设计
2.  宜人贷系统架构–高并发下的进化之路

两篇文章其实都是讲架构的迭代和演化性，值得每个架构师学习吸收。

# 构建闭环反馈架构 #

先分享一个链接，这几年对我架构影响最深的一篇文章。这篇文章是关于DevOps的，但对系统架构同样适用：

> http://itrevolution.com/the-three-ways-principles-underpinning-devops/

![每个架构师都应该研究下康威定律][233273645c044c718d574b27b8b3d251]

第一条道路，**系统思维**，开发驱动的组织机体，其能力不是制作软件，而是持续的交付客户价值，架构师需要有全局视角和系统思维（System Thinking），深入理解整个价值交付链，从业务需求、研发、测试、集成，到部署运维，这条价值链的效率并不依赖于单个或者几个环节，局部优化的结果往往是全局受损，架构师要站在系统高度去优化整个价值交付链，让企业和客户之间形成快速和高效的价值传递。

![每个架构师都应该研究下康威定律][6cd94e1ffe774dedbc3f1c5f64063393]

![每个架构师都应该研究下康威定律][b4cc8f06426f4ab0a46a0389bdd87b4c]

第二条道路，强化反馈环，任何过程改进的目标都是加强和缩短反馈环。刚入行的工程师，也是中国学生的普遍问题，就是生产运维意识不足（监控是系统反馈的重要环节）。有两种化这样讲的：

1.  no measurement, no improvement没有测量，就没有改进和提升
2.  What your measure is what you get你测量什么，就得到什么

没有监控或者监控不完善的系统相当于裸奔，开车上高速无仪表盘。有一篇很多错的关于测量驱动开发的文章，在InfoQ上的，向大家推荐：

> http://www.infoq.com/cn/articles/metrics-driven-development

这篇文章提出了度量驱动开发的理念，即所谓MDD，在系统，应用和业务，通过三级监控，构建三个反馈环，在监控测量基础上持续改进系统和架构，我最近也在参考这个理念设计一个电商平台的技术架构，见下图：

![每个架构师都应该研究下康威定律][0fcfe6b91af34aafb2737e17e37ea647]

这是一个电商平台的架构，整个体现了闭环架构的思想，右侧是整个平台的反馈监控环节。具体如下：

1.  系统层监控计算网络存储，构建系统层的反馈环
2.  应用服务层，监控业务、应用、服务，甚至整个研发流程，构建应用和服务层的反馈环
3.  客户体验层，监控端用户和分析网站用户的行为，构建和客户的反馈环

下面这个图展示了系统提升和改进的一般方法：

![每个架构师都应该研究下康威定律][7947a6215d4f4ec0bf58eeeb345ff4b6]

收集->测量->调整->闭环重复，在有测量数据和反馈的基础上，系统、应用、流程和客户体验才有可能获得持续的提升和改善，否则没有数据的所谓改进只能靠拍脑袋或者说猜测。

![每个架构师都应该研究下康威定律][da82b7964a4f4bc7b663ab9897f17b56]

第三条道路，**鼓励勇于承担责任，冒险试错和持续提升的文化**。这点是最难的，一般和企业人才密度有关。工具，技术，流程只是一个公司的冰山浮出水面的部分，而真正对企业效能影响大的则是冰山水下的部分，即企业的人和文化，架构师作为技术和架构的布道者，有责任义务鼓励和推动试错文化。

架构师要深入领会这三条道路，关注整个价值交付链的效率，关注每个环节的闭环反馈，鼓励和推动公司的试错文化，打造全系统的闭环架构（Architecting for closed loop feedback），提升整个系统效能。下图的DevOps和每日交付是每一个互联网系统架构师的梦想和努力的方向。

![每个架构师都应该研究下康威定律][4bb1c8052df543228a00a5ff36434592]

# 谈谈微服务架构 #

微服务我想大家都听得很多了，我本人也非常关注和推崇微服务，从技术角度讲，我认为微服务主要体现的是单一职责和关注分离的思想，从单进程模块化进一步拓展到跨进程分布式的模块化。微服务是独立的开发、测试、部署和升级单元，正如我在第一点架构定义中提到的，微服务中每个服务可以独立演变，它的cost of change比较小，整体架构比较灵活，是一种支持创新的演化式架构。

去年MartinFowler写了两篇文章，给微服务泼冷水的，建议大家好好读下。

1.  http://martinfowler.com/bliki/MicroservicePrerequisites.html
2.  http://martinfowler.com/bliki/MicroservicePremium.html

![每个架构师都应该研究下康威定律][e168907304d74afbb867c796970a46e6]

这个图讲什么时候该引入微服务。微服务有额外成本的，需要搭建框架、发布、监控等基础设施。初创和小规模团队不建议采用。主要决定因素系统复杂性和团队规模，当到达一个点，单块架构严重影响效率才考虑 。另外补充一点，**微服务更多是关于组织和团队，而不是技术**。

# 架构和组织文化关系 #

再谈一下康威定律：Conway’s law: Organizations which design systems\[...\] are constrained to produce designs which are copies of the communication structures of these organizations.

（设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。 )

从单块架构到微服务架构是这个定律的很到体现。

![每个架构师都应该研究下康威定律][84bfeeb6a123480eb4d35665e28583cc]

团队是分布式的，系统架构是单块的，开发，测试，部署协调沟通成本大，严重影响效率，严重时团队之间还容易起冲突conflict。

![每个架构师都应该研究下康威定律][1bb9b8c0b5da4130b4c920116b26c91b]

将单块架构解耦成微服务，每个团队开发，测试和发布自己负责的微服务，互不干扰，系统效率得到提升。

可见，组织和系统架构之间有一个映射关系（1 ~ 1 mapping），两者不对齐就会出各种各样的问题，一方面，如果你的组织结构和文化结构不支持，你也无法成功建立高效的系统架构，例如集中式和严格职能（业务, Dev, QA, Deployment, Ops）的企业，很难推行微服服务和DevOps，推行Docker/PaaS平台也会比较困难，这样的组织职能之间都倾向于局部优化（local optimization），无法形成有效和合作和闭环。

反过来也是成立的，如果你的系统设计或者架构不支持，那么你就无法成功建立一个有效的组织；作为系统架构师，一定要深入领会康威定律，设计系统架构之前，先看清组织结构，也要看组织文化（民主合作式，集权式，丛林法则式，人才密度），再根据情况调整系统架构或者组织架构。

# 架构师心态和软技能 #

空杯，或者说开放心态（open minded）是一个成熟架构师的应有心态，stay hungry, stay foolish， 心态有多开放，视野就有多开阔。来自《高效能人士的七个习惯~史蒂芬~柯维》的一句话送给每一个架构师 :

**如果一位具有相当聪明才智的人跟我意见不同，那么对方的主张必有我尚未体会的奥秘，值得加以了解。与人合作最重要的是，重视不同个体的不同心理、情绪与智能，以及个人眼中所见的不同世界。与所见略同的人沟通，益处不大，要有分歧才有收获。**

另外再推荐一个本书《软件架构师的12项修炼》，这书中三个观点很值得每个架构师学习领会:

1.  soft skills are always hard than hard skills，软技能比硬技能难
2.  choosing relationship over correctness ，注重关系重于谁对谁错
3.  架构的政治性，在中大型公司里混的架构师尤其要学习

政治指的是和他人协作将事情搞定的艺术，架构是一种社交活动，在技术的世界里，个人主义很容易被打败，即使你的目的是好的技术是最优的，技术决策是政治决策（technical decisions are political decisions），一个技术产品，一波人可以做，另一波人也可以做，到底谁做的好，真不好说，不管谁做，都给业务套上了一副手铐。

架构师如何提升？实战，实战，实战！规划职业，找好的团队和项目，总结分享，学习GitHub开源项目，尽可能参与和开创自己的开源项目和产品，并长期积累。

# 我对一些架构师争议主题的看法 #

主要争议是两个话题：

1.  技术和业务的关系。
2.  架构师要写代码吗？

架构师怎么回答这类问题？一个成熟架构师的口头禅：视情况而定，不一定，是也不是，it depends。技术和业务，架构师要理解业务吗，看产品和客户，如果是业务性产品，肯定要理解业务，如果是技术型产品，就不一定。

架构师要写代码？也不一定，个人觉得尽可能要写，如果你写过十年以上代码了，每年不少于2万行，都玩通了，可以不写。另外架构师如果写代码，要把控度，不要一头钻入代码，花大量时间解决细节和复杂性问题，忽视全局和系统性问题。

# 最后 #

我想说中国现在的互联网发展趋势很好，越来越多的人加入架构师这个行业，这个行业正在“万物生长”。 但是我们现在还没有马丁福勒，adrian cockcroft这样的架构牛人物，我辈需不断努力，期待中国10~20年后出现超过十个马丁福勒，adrian cockcroft这样的大牛神级人物。我们必不可停止探索，而一切探索的尽头，就是重回起点，并对起点有首次般的认识。

[4a56a99eb9b14b6286441b775a11850d]: /images/20220221/5308e46404c0430cb0b655bef7faaf05.png
[f27dc92f86d24f9781bf952dd6fd252d]: http://p1.pstatp.com/large/pgc-image/f27dc92f86d24f9781bf952dd6fd252d
[5ccb4ddf64d64c80a28426fdae80f991]: /images/20220221/6257dc14aea34a8e8dc2b7b0370e104d.png
[e50c96e9262c4bce8eb161afc214adc9]: http://p1.pstatp.com/large/pgc-image/e50c96e9262c4bce8eb161afc214adc9
[e083eec724b644d2bfbd3cd135387c4b]: http://p1.pstatp.com/large/pgc-image/e083eec724b644d2bfbd3cd135387c4b
[44546828b87747f8bd880d4658a44103]: /images/20220221/8152ba7f8d314b5497a0a8637c4b4b6c.png
[233273645c044c718d574b27b8b3d251]: http://p1.pstatp.com/large/pgc-image/233273645c044c718d574b27b8b3d251
[6cd94e1ffe774dedbc3f1c5f64063393]: http://p1.pstatp.com/large/pgc-image/6cd94e1ffe774dedbc3f1c5f64063393
[b4cc8f06426f4ab0a46a0389bdd87b4c]: http://p1.pstatp.com/large/pgc-image/b4cc8f06426f4ab0a46a0389bdd87b4c
[0fcfe6b91af34aafb2737e17e37ea647]: /images/20220221/57ac6284231143858748942aff3b5c88.png
[7947a6215d4f4ec0bf58eeeb345ff4b6]: /images/20220221/31be0b00021d4f88ac6b0d3a1dc48d9d.png
[da82b7964a4f4bc7b663ab9897f17b56]: http://p9.pstatp.com/large/pgc-image/da82b7964a4f4bc7b663ab9897f17b56
[4bb1c8052df543228a00a5ff36434592]: http://p1.pstatp.com/large/pgc-image/4bb1c8052df543228a00a5ff36434592
[e168907304d74afbb867c796970a46e6]: /images/20220221/56b08a1bc79a422098ac44c690fda22e.png
[84bfeeb6a123480eb4d35665e28583cc]: http://p1.pstatp.com/large/pgc-image/84bfeeb6a123480eb4d35665e28583cc
[1bb9b8c0b5da4130b4c920116b26c91b]: /images/20220221/788a0aadb55f45c8ae117e4508c47195.png