每个架构师都在研究的康威定律，程序员进阶路上，你思考过吗？ _康威定律

背景今天的分享主要来自我之前的工作经验以及平时的学习总结和思考。我之前的背景主要是做框架、系统和平台架构，之前的工作过的公司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总结起来就是三个特点：