波波的架构理念

背景

近期我会陆陆续续把我之前在infoq/聊聊架构等媒体上发表的文章，陆续搬到我的CSDN博客上，这个是第一篇。

这篇有特殊的意义，2015年下半年的时候，我还没有养成定期总结梳理的习惯，是极客邦的郭蕾鼓励我尝试。今天回头看，这个投资有很大价值，这一路积累了不少东西，后面需要持续积累，将价值和影响力进一步扩大化。

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

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

一、我对架构定义的理解

大概10年前，我曾经有一个对口的美国架构导师，他对我讲架构其实是要找出干系人（stakeholders），然后解决他们的关注点(concerns)。后来我读到一本书《软件系统架构：使用视点和视角与利益相关者合作》，里面提到的理念也是这样的：系统架构的目标是解决利益相关者或者关系人的关注点。

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

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

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

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

上图是我上次在公司内分享的一个图，

上图是在slideshare上的一个ppt里头截取出来，两个图都是列出架构师经常需要关注的非功能性需求。

另外，去年我偶尔看到UML创始人Grady Booch是这样描述架构的：

“Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change”。
翻译成中文就是，架构表示对一个系统的成型起关键作用的设计决