每个架构师都应该研究下康威定律分解.docx

每个架构师都应该研究下康威定律  编者按：这篇文章的分享者杨波具有超过 10年 的互联网分布式系统研发和架构经验，曾先后就职于 eBay 中国研发中心（eBay CDC）、携程、唯品会（VIPShop）等。本文由攀爬的蜗牛以及田光整理。36 氪经授权转载自微信公众号“聊聊架构”。聊聊架构是 InfoQ 旗下的垂直社区，主要关注传统企业以及互联网企业的系统架构，微信号：archtime。 今天的分享主要来自我之前的工作经验以及平时的学习总结和思考。我之前的背景主要是做框架、系统和平台架构，之前的工作过的公司 eBay、携程、唯品会都是平台型互联网公司，所以今天主要带着平台架构视角和大家分享心得体会。架构的视角每个人都不一样，可以说一万种眼光，有业务架构、安全架构、平台架构、数据架构，各不相同，这里仅是我的一家之言，欢迎大家加入『聊聊架构』社群参与讨论。今天聊的话题主要包括以下几点： ? 我对架构定义的理解 ? 架构的迭代和演化性 ? 构建闭环反馈架构（Architecting for closed loop feedback） ? 谈谈微服务架构和必威体育精装版主题 ? 架构和组织文化关系 ? 架构师心态和软技能 ? 我对一些架构师争议主题的看法 我对架构定义的理解 大概在 7~8年 前，我曾经有一个美国对口的架构师 mentor，他对我讲架构其实是发现利益相关者（stakeholder），然后解决他们的关注点（concerns），后来我读到一本书《软件系统架构:使用视点和视角与利益相关者合作》，里面提到的理念也是这样说：系统架构的目标是解决利益相关者的关注点。 这是从那本书里头的一张截图，我之前公司分享架构定义常常用这张图，架构是这样定义的： ? 每个系统都有一个架构 ? 架构由架构元素以及相互之间的关系构成 ? 系统是为了满足利益相关者（stakeholder）的需求要构建的 ? 利益相关者都有自己的关注点（concerns） ? 架构由架构文档描述 ? 架构文档描述了一系列的架构视角 ? 每个视角都解决并且对应到利益相关者的关注点。 架构系统前，架构师的首要任务是尽最大可能找出所有利益相关者，业务方，产品经理，客户 / 用户，开发经理，工程师，项目经理，测试人员，运维人员，产品运营人员等等都有可能是利益相关者，架构师要充分和利益相关者沟通，深入理解他们的关注点和痛点，并出架构解决这些关注点。架构师常犯错误是漏掉重要的利益相关者，沟通不充分，都会造成架构有欠缺，不能满足利益相关者的需求。利益相关者的关注点是有可能冲突的，比如管理层（可管理性）vs 技术方（性能），业务方（多快好省）vs 技术方（可靠稳定），这需要架构师去灵活平衡，如何平衡体现了架构师的水平和价值。 关于架构的第二点定义是说架构主要关注非功能性需求（non-functional requirements），即所谓的-abilities。 这个是我上次公司内分享的一个图。 这个是 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 总结起来就是三个特点： ? 用例和风险驱动 Use Case and risk driven ? 架构中心 Architecture centric ? 迭代和增量 Iterative and inc