最近研读了不少关于架构师的书籍和文章，通过这篇文章对所阅的内容做一个总结，与大家分享。总的来说，如果一个技术人员想成长为一个合格的架构师，不仅需要技术上的优势以及对业务的深入理解，同时对架构师这个角色也需要有深刻的理解，知道什么是架构，以及为什么需要架构，只有这样，才能最终成长为一个合格的架构师。
一、什么是架构？
所谓架构，就是对要解决的问题的边界进行界定，并根据界定的边界对目标系统进行切分，保证多个角色能够并行或者串行地工作，最终基于有效的沟通机制，保证切分的部分能够有效地整合在一起，完成目标系统所有工作。
二、为什么需要架构？
1、架构解决的是人的问题。
架构产生的原因最终还是为了解决人的问题，是与人的利益相关的。每个人的能力有限、时间有限，同时人对目标系统有更高的要求，但是在更高的要求下，目标系统的复杂性使得单个人完成这个系统比较困难，此时就需要通过架构来解决，帮助人解决问题。
2、架构的目标是用来解决利益相关者的关注点。
这里的利益相关者包括业务方、产品经理、客户/用户、项目经理、研发人员、运维人员、运营人员。由于这些相关者存在没有解决的关注点以及通电，因此需要架构来进行解决。
三、怎样做架构？
1、识别真正的问题。
识别真正的问题，就是要发现利益相关者的关注点和痛点，找出问题所在，并根据要解决的问题，对目标系统的边界进行界定。
识别真正的问题的第一要点是要找出问题的主体，是谁的问题？架构师要有这个自觉：真正的问题不需要找架构师，发现问题永远都比解决问题更重要。
识别真正的问题的第二要点是要找出到底是什么问题。只有确定了问题的主体，才能明确问题的边界，最终找出是什么问题。
2、对架构进行切分。
切分的导火索是人的负载太重；
切分的原则是便于不同的角色，对切分出来的部分并行或者串行地开展工作；
切分的每个部分的责任人的权利义务对等，对自己的利益负责。
切分的最终结果都会落地到组织机构上，才能让架构落地并推进；康威定律：设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。
架构的切分一定是树状的，而且层次越少越好，尽可能是一棵平衡树。
3、对切分部分设立沟通机制。
对这些切分出来的部分，设立沟通机制，使得这些部分能够进行有效的联系，合并组装成一个整体，完成目标系统的所有工作。
4、架构具有迭代和演化性
在系统真正投入生产使用之前，再好的机构都只是假设，产品越晚被使用者使用，失败的成本和风险就越高。
通过最小可用产品理念，做出最小的可用产品，尽快获取客户的反馈，迭代演化产品，能够有效减少失败的成本和风险。
5、构建闭环反馈架构
企业通向DevOps的三条必经之路：
第一条道路：系统思维
开发驱动的组织机体，其能力不是制作软件，而是持续交付客户价值。架构师需要由全局视角和系统思维，深入理解整个价值交付链，从业务需求、研发、测试、集成到部署运维。
第二条道路：强化反馈环
任何过程的改进的目标都是加强和缩短反馈环。
度量驱动开发：在系统、应用和业务三个层次，通过三级监控，构建三个反馈环，在监控测量基础上持续改进系统和架构。
1、系统层监控计算网络存储，构建系统层的反馈环。
2、应用服务层，监控业务、应用、服务，甚至整个研发流程，构建应用和服务层的反馈环。
3、客户体验层，监控端用户和分析网站用户行为，构建和客户的反馈环。
第三条道路：鼓励勇于承担责任、冒险试错和持续提升的文化
架构师要深入领会这三条道路，关注整个价值交付链的效率，关注每个环节的闭环反馈，鼓励和推动公司的试错文化，打造全系统的闭环架构，提升整个系统效能。
6、领会康威定律
设计系统架构之前，先看清组织架构，也要看组织文化（民主合作式、集权式、丛林法则式、人才密度），再根据情况调整系统架构或者组织胶骨。
如果团队是分布式的，系统架构是单块的，开发、测试、部署协调沟通成本大，严重影响效率，严重时团队之间还容易起冲突。
集中式和严格职能（业务、开发、测试、运维、部署）的企业，很难推行服务和DevOps，推行Dockers/PaaS平台也会比较困难。
