遥不可及|每个架构师都在研究的康威定律，程序员进阶路上，你思考过吗？( 四 )
谈谈微服务架构微服务我想大家都听得很多了 ， 我本人也非常关注和推崇微服务 ， 从技术角度讲 ， 我认为微服务主要体现的是单一职责和关注分离的思想 ， 从单进程模块化进一步拓展到跨进程分布式的模块化 。 微服务是独立的开发、测试、部署和升级单元 ， 正如我在第一点架构定义中提到的 ， 微服务中每个服务可以独立演变 ， 它的cost of change比较小 ， 整体架构比较灵活 ， 是一种支持创新的演化式架构 。
这个图讲什么时候该引入微服务 。 微服务有额外成本的 ， 需要搭建框架、发布、监控等基础设施 。 初创和小规模团队不建议采用 。 主要决定因素系统复杂性和团队规模 ， 当到达一个点 ， 单块架构严重影响效率才考虑。 另外补充一点 ， 微服务更多是关于组织和团队 ， 而不是技术 。
架构和组织文化关系再谈一下康威定律：Conway’s law: Organizations which design systems[...] are constrained to produce designs which are copies of the communication structures of these organizations.
（设计系统的组织 ， 其产生的设计和架构等价于组织间的沟通结构 。)
从单块架构到微服务架构是这个定律的很到体现 。
团队是分布式的 ， 系统架构是单块的 ， 开发 ， 测试 ， 部署协调沟通成本大 ， 严重影响效率 ， 严重时团队之间还容易起冲突conflict 。
将单块架构解耦成微服务 ， 每个团队开发 ， 测试和发布自己负责的微服务 ， 互不干扰 ， 系统效率得到提升 。
可见 ， 组织和系统架构之间有一个映射关系（1 ~ 1 mapping） ， 两者不对齐就会出各种各样的问题 ， 一方面 ， 如果你的组织结构和文化结构不支持 ， 你也无法成功建立高效的系统架构 ， 例如集中式和严格职能（业务, Dev, QA, Deployment, Ops）的企业 ， 很难推行微服服务和DevOps ， 推行Docker/PaaS平台也会比较困难 ， 这样的组织职能之间都倾向于局部优化（local optimization） ， 无法形成有效和合作和闭环 。
反过来也是成立的 ， 如果你的系统设计或者架构不支持 ， 那么你就无法成功建立一个有效的组织；作为系统架构师 ， 一定要深入领会康威定律 ， 设计系统架构之前 ， 先看清组织结构 ， 也要看组织文化（民主合作式 ， 集权式 ， 丛林法则式 ， 人才密度） ， 再根据情况调整系统架构或者组织架构 。
架构师心态和软技能空杯 ， 或者说开放心态（open minded）是一个成熟架构师的应有心态 ， stay hungry, stay foolish ，心态有多开放 ， 视野就有多开阔 。 来自《高效能人士的七个习惯~史蒂芬~柯维》的一句话送给每一个架构师 :
如果一位具有相当聪明才智的人跟我意见不同 ， 那么对方的主张必有我尚未体会的奥秘 ， 值得加以了解 。 与人合作最重要的是 ， 重视不同个体的不同心理、情绪与智能 ， 以及个人眼中所见的不同世界 。 与所见略同的人沟通 ， 益处不大 ， 要有分歧才有收获 。
另外再推荐一个本书《软件架构师的12项修炼》 ， 这书中三个观点很值得每个架构师学习领会:
