多种因素驱动着技术架构复杂性不断增大，要做好运维管理难度将呈指数增大。在运维过程中，运维需要持续推进架构的优化，比如应用与数据库在服务器层面分离，利用集群部署方式提升并发能力，数据库读写分离提升数据库性能，反向代理及CDN加速提升前端访问速度，拆分业务或数据库提升性能，同步改异步方式提升并发能力，有损服务与降级提升故障恢复能力等。发挥运维核心价值，不仅要保障基础设施层面的高可用，还要不断向业务侧深入，加强软件架构管理能力。同时，架构是运维数字世界的骨架，沉淀了团队众多专家的经验，是一项核心资产，需要在运维侧建立架构管理的工作机制，沉淀架构资产，达到持续提升业务连续性、加快软件交付速度、提高服务质量、提升客户体验的运维价值创造。
3.4.1关于架构
技术架构是一个基础设施、应用平台、企业应用系统、应用模块的技术基础，是根据业务、技术、组织、可扩展性、可维护性等因素驱动，由企业研发、测试、运维，以及供应商、业务人员等领域专家对信息系统的知识沉淀。运维要深入了解系统，需要深入理解架构，优化架构，并为架构提供标准及平台能力支持。
百度百科中，对软件架构作了定义“是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计，是一个系统的草图，描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。”以下，尝试从定义中摘四个关键词：模式、组件、连接、描述，看看架构：
- 模式：解决特定问题提出的通用、可重用的解决方案，比如分层、事件驱动、分布式、缓存、异步、冗余等。
- 组件：独立的模块，比如应用服务、数据库、中间件等。
- 连接：组件间的调用、访问关系。
- 描述：对模式、组件、连接的整体描述，比如架构图。
也就是说，理解一个技术架构先理解是属于哪一种或哪几种模式组成，基于这些模式我们通常都能相对方便的获得最佳实践的指导，了解模式也是为了将复杂、多样化的业务、中间件、数据库、基础设施等信息进行抽象简化，更好的理解及执行举措。接下来是梳理组成系统的技术组件，组件是基于模式最佳实践进行配置。组件之间会产生关系而非孤立运行，系统内部组件之间以及系统间组件之间会有调用访问关系，应用层的组件与系统、中间件、平台、基础设施之间也会有纵向的依赖关系。架构很重要，但要让架构真正赋能运维，需要让架构可观察，需要利用数字化手段描述架构，让架构可观察，更好的使用。
3.4.2常见架构（done）
技术架构的核心价值是为业务服务提供最优解，只有最合适的架构，以下从应用、系统软件、基础设施3个层面大概罗列一下在运维过程中经常关注的架构。
1.应用层面
单体、SOA、微服务是软件层面常见的三种技术架构，对于运维而言，每种架构都有各自的优劣势。
（1）单体架构
在企业存量系统中，尤其是内部管理类，或对并发要求不高，或变更迭代少系统，很多属于单体架构。单体架构通常指所有功能模块的制品打包在一起，并部署在一个中间件容器中运行，单体架构广泛应用在存量比较旧的系统以及一些简单应用。在运维侧，单体架构有利有弊，好的地方是系统架构逻辑简单好理解，应急保障、变更部署、技术验证及测试、系统扩容方案等运维行为容易固化、标准化，有利于专家经验的培养；不好的地方是单体架构面临模块紧耦合，制品包过大，牵一发动全身，可维护性、扩展性会随着时间推移而降低，维护成本会加大，故障隔离性差，程序故障修复慢。
（2）SOA
面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，每个组件对应一个完整的业务逻辑，并通过这些服务之间定义良好的接口和协议联系起来。与单体架构相比，SOA架构采用一种松耦合服务架构，以服务为中心各个系统之间依靠ESB进行调用。从运维侧看，SOA的架构在初期通常会给运维增加难度。从运维人员角度，单体架构从硬件服务器、中间件、应用程序、数据库等组件部署方式很清晰，当出一个故障时，运维人员凭经验即可快速定位问题。但是采用SOA架构，软件、服务部署在不同的设备上，同一个业务涉及多个系统、多个团队的协同，而某一个服务组件的单点或异常也会产生全局性的影响。好在，随着应用架构高可用不断完善，以及运维工具平台赋能，改善了SOA架构的运维难度，并更好的利用好SOA带来的扩展性。
（3）微服务
微服务在SOA的基础上，强调了服务组件的“微”，微服务的每个服务对应单独的功能或任务，同时微服务不再强调SOA架构中ESB企业服务总线这种中央管控式的架构。由于每个服务都专注某一细分的功能，逻辑相对单一，单个服务更加易于开发与维护，在架构上更利于扩展性。同样，站在运维侧，微服务带来一系列优点同时，也进一步增加了运维的难度，原来一个单体系统主要采用几台强大性能的服务器部署，而采用微服务可能会被拆成几十个服务部署在不同的服务器上，调用链路更加复杂。
2.系统软件层面
（1）数据库
数据不丢是运维的生命线，数据库架构重点围绕高可用、高性能、一致性、扩展性。常见的数据库架构高可用方案包括：
主备架构：主机负责读写，备机只负责故障转移，通常采用主备共享一份数据存储，或采用数据复制方法同步数据到备机。主备切换通过心跳机制自动或手工切换，分别对应热备与冷备。
主从架构：包括一主一从或一主多从的架构，主机负责写，从库负责读，实现读写分离，主从架构根据应用需要可以设置主从数据一致性要求。
分布式架构：重点解决了大表的读写问题，通常是利用数据库分布式中间件，实现数据库事务、数据处理。数据库中间件使底层分布式数据对于上层应用而言是透明的，相当一个逻辑数据库。在数据库分布式中间件下，对原本大表进行分库分表。
针对数据库性能问题，通常首先会从SQL语句、索引、清理数据、优化程序逻辑等方式进行优化。其次是架构层面的优化，比如主备架构的优化通常采用纵向扩容方式，即加服务器资源，换性能更强的服务器提升服务能力，或迁移大表；或从应用角度将查询多与写入多的逻辑区分开，对应将数据库进行垂直切分成多个数据库。
（2）其他模块
其他系统软件的组件还包括：像服务注册与发现涉及的ZK、Eureka，消息中间件中的kafka，多种XXXXMQ，DNS域名解释服务，CDN服务，nginx等负载均衡软件，ES搜索引擎等，这些主流的架构组件通常都会有一些比较成熟的部署方案。我觉得运维侧重点要推动研发对于组件的标准化，同时配备相应的云资源服务，以及监控、自动化相关工具，以更好的支持此类组件模块的可维护性。
3.基础设施层面
基础设施层面，对于金融行业，在数据中心层面主要采用两地三中心的架构，三中心指主中心、同城备份中心、异地灾备中心，在实际的实施上有些企业会在两地三中心基础上增加同城灾备中心解决异常灾备中心数据同步时效性问题，租用异地机房解决终端接入，或引入行业云、公有云补充弹性扩容能力等方式，组成了混合云的基础设施架构。对于应用系统架构，基础设施层架构一方面屏蔽了基础设施层的复杂性，提供良好扩展性的基础设施服务；另一方面基础设施架构也向上层应用提出双活、多活等更高的要求，驱动应用系统的架构升级，云原生应用架构、微服务架构模式为新的业务系统架构提供了最佳实践，在用的存量系统则是另一个难题。
3.4.3运维侧关注的架构问题（done）
不同的岗位角色对于架构的关注点不同，比如业务架构师重点业务规划，业务模块、业务流程，对整个系统业务进行拆分，对领域模型进行设计，抽象模型；研发工程师重点关注架构分层、数据模型、设计模式、接口、数据交互等，运维工程师则更关注高可用、故障恢复、性能扩展性、数据完整性、数据备份、自动化及灰度发布、可观察等。
1.高可用角度
站在运维角度看技术架构的高可用，通俗的话就是消灭单点风险，像前面数据库中提到的主备、主从、分布式，以及数据中心的两地三中心都是高可用方案之一，而像RPO与PTO则是高可用的量化评估方案。运维强调高可用主要是由于运维面临的研发团队通常更关注业务功能的实现，而对架构的高可用关注较少，这种情况尤其出现在新系统交付生产的情况。所以，一方面，运维需要在硬件、软件、平台等层面，为应用提供高可用的基础服务能力，比如将一个应用系统同一个服务组件部署在多个数据中心机房，不同物理机的多个虚拟机上，为应用的负载均衡提供网络硬件或软件负载均衡器，提供具备高可用架构的数据库、消息中间件等PAAS云服务。另一个方面，运维需要提前提供架构高可用的规范，制定通用组件高可用技术参考模式，将高可用理念更早的落地在研发过程中。
2.性能角度
关于性能会有一些黄金指标，比如：响应时间（系统，功能，或服务组件完成一次外部请求处理所需的时间）、吞吐率（在指定时间内能够处理的最大请求量）、负载（服务组件当前负荷情况）、效率（性能除以资源，比如QPS=并发量/平均响应时间）、可扩展性（垂直或水平扩容的能力）等是运维需要关注的一些性能指标。
性能问题对于运维的挑战不仅仅是单组件不可用，更严重的是某个组件性能问题不断扩散到别的组件，导致大规模的故障，这种故障可能是由于一个极小的问题迅速扩散出去。业务运维可能经常会遇到这样的场景：某个服务组件功能响应时间增长，外部请求等待时间增加，等待的并发进程增加（假设响应时间过长、非异部响应），数据库并发连接数增加，数据库连接数据全部占满，数据库无法接收新的请求，引发全局性故障。这类性能问题在谷歌SRE解密一文中有一章关于连锁故障的介绍。运维需要驱动研发侧一起梳理这类链路请求的风险点，故障恢复角度进行架构的优化。
3.故障恢复角度
从架构角度看故障恢复，运维可以依据一些最佳实践的思路，推动架构的优化，比如：
- 应用拆分：逻辑上分析业务主流程，将分支交易进行分离，按业务功能拆分独立的服务；物理上将独立的服务进行分离，独立部署，出现问题后可以快速采取措施进行隔离或扩容。
- 服务或系统交互解耦：如WEB到逻辑服务前加队列层，减少前端放开流量导致后端处理能力跟不上的问题；数据库前加上缓存层，减少数据库的并发压力。
- 减少总线节点服务的依赖：由多节点组成的逻辑交互改为端对端的访问方式，一方面减少影响交易的因素，另一方面减少自身性能问题影响其它应用系统。
- 增加异步访问机制：同步的机制在性能出现问题时，会在短时间花完最大连接数，哪怕这个最大并发数是正常情况下的10倍。这方面可以直接改异步通讯，也可以引入一些队列工具实现。
- 多层次的缓存：缓存的引入可以多层次，从前端、应用内部、数据库等，比如：前端页面可以利用缓存技术减少页面刷新，这方面可以采用网络工具解决；数据库前可以采用REDIS等；应用自身同样可以用缓存代替数据库的读操作；
- 数据库优化：1）架构上：拆库、在线库与历史库分离、分布式数据库、读写分离、非关系型数据库。比如：第1点应用拆分后，则可以按业务拆库；分布式数据库实现数据分片读写等等。2）编码上：SQL优化、索引新增、数据定时清理，这个优化方式最快，最容易出效果；减少数据库访问次数、减少数据库一次返回的结果集；
- 前端限流、削峰机制，前端系统因为逻辑简单往往可以支持更多请求，但后端系统则不同。所以需要前端系统做交易并发控制，并通过一些前端交互设计减少客户的体验影响；
- 基础设施支持快速扩容：支持弹性扩容（第1点系统拆分独立部署很重要，可以减少扩容复杂性）。
- 服务降级：重要服务重点保障，次要服务有损保障，紧急情况下进行降级。
4.数据角度
大部份系统都会涉及持久化数据的相关组件，比如像关系型与非关系型数据库，文件内容管理等组件，对于数据通常需考虑架构的高可用、事务一致性、数据完整性、性能扩展能力、运行及运营数据监控管理等；同时，持久化数据的生命周期会比系统与硬件的生命周期还要长，很多新系统上线或架构调整都考虑数据迁移的工作；另外，还有一些系统涉及一些复杂性的数据处理，比如：批次、清算、对账等操作，这些操作极易受数据问题影响，运维侧需要关注数据处理的异常中断原因定位、哪些环节是可以应急断过、中断后是否支持多次重试、与第三方系统约定数据不一致时以哪方为基准等等应急处置机制；最后，随着系统复杂度变高，系统产生了更多的数据，数据被应用的场景更多，对数据准确性与性能响应要求更高，这要求运维能够加强数据准确性的管理，比如如何加强应急数据维护的准确性，减少脏数据，同时也要求运维能够增加对数据性能的管理。
5.非功能设计角度
从运维侧出发看非功能性设计，重点关注系统的可运维性，可运维性的好坏直接决定了系统在生产环境的成本与收益，甚至决定系统的生命周期的长短。以下尝试罗列一下运维侧需要推动的非功能设计：
- 系统运行状况可观察。可观察主要包括：监控、日志、链路三块，很多时候运维是在一个成品上进行监控、日志、链路的完善，像NPM、APM、BPM等是运维侧发起的一些方案。从非功能设计看可观察，需要运维前移，推动必要的监控、日志、链路相关的研发规范，提升主动上报监控性能指标数据的能力，优化日志的可读性，并提供必要的基础设施服务支持，比如支持系统监控数据上报、日志采集分析等。
- 故障隔离与服务降级。故障隔离和服务降级的目的是以牺牲部分业务功能或者牺牲部分客户业务为代价，保障更关键的业务或客户群体服务质量，是防止连锁性故障蔓延的方法。在设计中，运维侧需要从系统或业务角度，梳理应用系统所调用的各个服务组件，对各个服务组件出现故障时的假设，及应对措施。
- 终端版本向下兼容。移动化后终端版本的管理越来越重要，在架构上一方面需要尽量保证升级后的版本要向下兼容正在流通的低版本的可用性；另一方面要对流通的版本进行收敛管理，支持多种在线更新机制。
- 基于公司平台运行。无论是基础设施平台，还是PAAS层的应用平台，或持续交付工具链，系统均需要尽量与公司现有平台对接，避免引入新的技术栈。
- 性能冗余设计。系统设计时要考虑最高并的情况，并在些基础上增加性能支持的能力，防范业务量突增带来的性能影响，相比业务连续性，资源成本的控制应排后。
- 可配置而非硬编码。经常在应急时，发现有些“参数”硬编码在程序中，无法快速调整。另外，像IP这类信息的DNS域名改造也是可配置的一个方向，减少人工在后台修改。
3.4.4架构管理流程（done）
1.持续评估与优化
运维侧推动的架构评审，按软件生命周期看，主要包括四类：
一是运维工作前移，在新项目设计阶段进行架构评审。这类评审需标准化先行，由运维侧先提供高可用、性能、故障恢复、数据、可维护性涉及的架构要求，并根据标准提供必要的基础设施服务能力，让研发侧能更好的适配相关架构要求。评审发现的问题，最好能够作为一份备忘录，在上线变更前进行审核确认，所以这项评审需要更早的介入，否则发现的问题无法得到有效解决。
二是上线前的变更评审。这类评审通常是review一下是否有重大的架构风险，会影响现有业务或新业务的连续性，以决策何时变更，以及变更涉及的相应的保障措施。评审发现的问题，根据紧迫程度需要由变更评审会建立相应的待跟踪任务。
三是系统上线后主动组织的架构评审。这种架构评审是针对存量系统进行主动的架构评审，和设计阶段的架构评审相比，这里的评审更加细致，范围上可以是高可用、性能、故障恢复、数据、可维护性的所有点评审，也可以围绕某一个点进行专题的评审。评审后的改进工作，通常可以通过问题单或任务的方式进行跟进。
四是基于事件驱动推动的架构评审。事件驱动的架构评审通常是针对某个生产故障、风险事件，或外部监管要求等，围绕某个特定的主题，可以针对事件涉及的系统，也可以举一反三扩大系统范围。
在架构评审过程中，建议有几个方法供参考：
- 明确围绕评审目标范围，比如前面提到的“高可用、性能、故障恢复、数据、可维护性”。
- 有标准才有公信力，师出有名；
- 流程机制保障评审的落实与评审结果跟踪到位；
- 更早做评审，更早发现问题；
- 持续优化的checklist；
- 让评审专家有“权、利”；
- 以“找问题，找亮点”方式挖掘风险点，推广最佳实践；
- 设计好评审会的计划、角色、过程；
2.架构资产管理
架构是团队专家经验的结果，要将架构资产化，得到专家经验的传承，架构图的管理是架构资产化的一个输出物。架构图的类型比较多，以4 1的架构视图为例，包括：
- 逻辑视图：主要针对服务组件需求，即系统给用户提供哪些服务。
- 开发视图：主要针对软件在开发环境下实现模块的关系。
- 过程视图：主要针对组件之间的通讯关系。
- 物理视图：主要针对物理或系统软件环境，物理即服务器或终端，系统软件即虚拟机、容器等。
- 场景视图：主要从功能角度的关系。
运维需要关注逻辑、过程、物理、场景四类架构图，以往我们主要用一些办公文档进行管理，存在架构图信息难更新，且架构信息协同传递效果不佳等问题。要将架构图按资产化管理起来，需要回到架构的几个要素：模式、组件、关系、描述，要让架构图中的模式分类，服务组件、组件关系数字化，通过线上化的架构图方式描述架构。同时还要让架构图成为能力融入到日常的工作场景中，比如在架构评审、应急管理、容量分析。
