架构师需要具备的能力

前言  

        万物需要架构，比如国家的职能部门，有国务院/工商局/教育局等。企业的组织架构，有研发部/市场部/产品部等。

        组织结构下的每一个部门，又会分很多角色，比如研发部，有技术部总监，技术Leader，技术架构师，研发工程师等，每个角色各自发挥角色价值。

        互联网企业中架构师能力的好坏会决定软件系统的好坏，这个好坏体现在维护性，扩展性，成本，业务支撑效率等。

        今天说说做好架构师工作需要具备的核心能力，该能力包括架构师的思维模式，架构师具备的架构原则，架构师深知的架构质量属性及程序设计的SOLID原则。当然在做架构设计时还需要知道架构的CAP定理。

01 架构师的思维模式

    架构师的核心工作是管理复杂，解决复杂。要解决复杂就需要运用抽象、分层、分治和演化4项思维。

    1. 抽象：架构师需要从大处着眼，隐藏细节，架构师抽象能力的高低，决定解决问题的复杂性和规模大小。在做架构时，需要先形成抽象概念，在进行模块细节设计，先宏观再微观。

    2. 分层：分层和分裂是架构师需要掌握的架构模式之一，重点在于降低系统间的耦合性，提升团队协作效率。

    3. 分治：架构师需要对问题进行分解，大问题分解小问题，小问题在分解小问题，先解决核心问题，影响架构质量要素的问题。

    4. 演化：架构既是设计出来，也是演化出来的，三分靠设计，七分靠演化，架构师需要根据业务发展演化架构设计，避免刻舟求剑。

02 架构师具备的架构原则 

    架构师需要知道6项架构原则，分别是分层分裂、异步、可用性、自动化、安全、分布式。

    1. 分层分裂：通过分层降低系统的耦合性，通过三层架构，每层专注自己职责；通过分裂提升协同开发的效率，一般按团队职责划分系统。

    2. 异步：通过异步削峰提升系统可用性和响应速度，特别是瞬间流量情况下，系统无法立即扩容的情况下保障系统可用性。

    3. 分布式：通过抽象共性模块，做到分布式服务，进而提升水平伸缩能力，比如分布式应用，分布式数据库，分布式存储。

    4. 集群冗余：互联网最核心的挑战有高并发、大流量，网络复杂，安全环境等，通过集群冗余，在出现故障时能够进行主备容灾，IDC容灾等快恢。

    5. 自动化：分布式系统核心的挑战是复杂，运维成本高，提升架构治理的自动化能力，做到自动化问题发现，定位，报警，故障转移，限流降级等提升系统稳定性。

    6. 安全防控：互联网本来是安全的，但是因为有人研究安全就变得不安全了，所以架构还需要通过一些技术安全手段，比如HTTPS，存储加密，Web安全风控，DDoS防御等手段提升系统的安全性。

03 架构师深知的架构质量属性

    架构师在架构软件系统时，除了知道6项架构原则外，还需要将架构转换成架构质量属性，提升客户体验，组织效率，具体映射到性能、可用性、安全性、成本、伸缩性、扩展性。

    1. 性能：性能是用户访问系统第一感受，性能太慢，会逐渐降低用户的忍耐度，最终离开。优化性能需要从客户端-网络-服务端-数据逐层优化，提升系统的响应时间，吞吐量，并发数。

    2. 可用性：在出现流量高峰，故障，网络问题时，能够具备快速发现、快速定位，快速恢复能力。常用的方法有负载均衡，主从备份，限流降级，多机房容灾部署。

    3. 伸缩性：过去通过购买小型机提升硬件能力，进而提升系统容量，但是互联网的高并发，无论垂直硬件能力如何提升，最终还是会触及天花板，互联网提升伸缩能力主要是分布式部署，通过负载均衡算法实现流量均衡分布。

    4. 扩展性：主要是从后期维护成本，和新业务支撑效率，通过对扩展开放和修改关闭，避免新需求对老业务产生影响。

    5. 安全性：核心是保障用户数据在网络传输上的完整性，避免被篡改。在遇到攻击时系统能够稳如泰山，不出现系统宕机。在网络传输，数据存储时保障机密性，比如密码不能明文传输。

    6. 成本：互联网大流量，意味着带宽，机器，存储，CDN资源都需要巨大的成本，如何降低各种资源成本，人力成本，成为架构师的必要工作。

04 程序设计SOLID原则

     架构师在做软件架构时，会根据架构原则、架构质量属性等指导原则提升系统的扩展性，可维护性等，还需要具备程序设计的SOLID原则，在指导研发同学，CR，方案评审时给出具体的指导意见，避免架构只停留在书面上。SOLID每个字母代表一个原则。

    1. 开闭原则：对扩展开放，对修改关闭。

    2. 接口隔离原则：接口保持最小精简和颗粒度，避免客户端依赖不需要的接口，简单理解为只需要暴露必要的接口。

    3. 里式替换原则：子类替换父类后，功能运行正常。

    4. 单一职责原则：一个类只有一个职责，如果修改一个类有多种理由，就不属于单一职责原则。

    5. 依赖倒置原则：上层模块（使用者）和下层模块（被使用者）都依赖中间的抽象层，上层模块依赖抽象注入能力，下层模块实现抽象的业务逻辑。

05 架构CAP定理

    C是一致性，A是可用性，P是分区容错性。但是在软件架构设计时一般无法同时满足CAP定理。

    比如金融系统要求高一致性，为了做到一致性，可能会牺牲可用性。软件设计上，一般会通过备份冗余的方式提高系统的可用性，但是备份冗余会存在数据的同步（不同副本间数据需要同步），数据肯定会存在延迟，所以金融系统的高一致性，背后是可用性降低。但是随着系统发展，可用性降低不代表系统完全不可用，遇到故障时，达到基本可用，或者核心链路服务可用，其他功能降级。

    反过来，互联网企业更在意高可用性，牺牲一致性，但是随着系统发展，一致性不是真的牺牲，只是短暂不一致，最终还是会形成最终一致性，比如通过解析mysql binglog完成副本数据同步实现最终一致性。

06 总结

    以上比较简单简洁介绍了架构师的能力，具体到每个类目下的每个概念都是一个非常大的话题，值得仔细深入研究，提升自己的架构能力。

    推荐阅读：《大型网站分布式架构》