前言

最近觉得自己一直在瓶颈。本想发发牢骚，后来觉得大可不必，也就没怎么更新博客。于是就买了市面上的一些书学习学习，博采众长。今天这篇博客主要介绍一下高可用和基础平台相关的一些架构知识。一部分得益于《携程架构实践》的总结，一部分得益于之前的项目经验。如有遗误，欢迎指出。

基础设施

经历过不同规模的企业，更能体会到基础设施对产品迭代，运维管理，安全治理的影响。有人说治理的前提就是标准化，但在大公司永远是分分合合。中台如是，BU也如是。

• IAAS&PAAS（混合云/公有云/私有云）通过资源池化的方式提供了存储，计算，网络等资源。同样云原生的出现也促进了IAAS和PAAS的融合。

• 统一接入层真是个好东西，可惜这没有，能够完成端到端的流量清洗。同时还能够提供用户便捷接入。这种分层设计模式还体现在CAL，DAL上面。一旦分层，就能通过在新的Layer附加不同能力，例如：安全特性。

• 监控平台一般讲究端到端的，全链路的。整体来说还是数据采集到分析到可视化到告警通知的一套流程，是建设可观测性架构必不可少的东西。

  现在的大型企业往往进行着快速迭代，由此带来大量的持续集成与交付，好的发布平台既需要提高效率又需要质量保证（废话）。

• 大数据时代数据平台是必不可少的，数据的传输存储再加工，如何反馈到商业模式上，促进盈利？当然安全也是必不可少。

服务可靠性

站点可靠性(Site Reliability)的概念的我最初是从Google SRE里了解到，作为Devops的一种实践。包括了高可用，可操作，可维护等等，从规划到发布，从监控到响应，基本都会涉猎。

高可用

网站可用性的计算方式此处略过。

• 在确保业务高可用的同时要优先确保运维工具的高可用，避免出现问题无法及时解决，此处优先级为: 故障恢复工具 > 监控工具 > 资源交付工具（例如CRM平台）> 代码发布工具

• 一般来说高可用的工作模式有以下几中: A/S (A/P); A/A; Cluster; LB; (注: A为Active的缩写，S为Standby的缩写，P为Passive的缩写)

• 原理上来看，一般有容量管理、灾难管理和故障管理三个方面。通过对资源、故障的管控实现高可用。在容量管理方面一般有容量预估,冗余,限流,扩容,集群化; 在灾难管理上，一般会做两地三中心，即同城x2DC异地x1DC。除此之外还有冷备热备，不过并不推荐。故障管理方面一般是在应用层或系统层面做降级或者熔断。通过预设条件降低异常的扩散，关闭某些非必要功能，维持原有系统的高可用。

• 从分层架构来看，所涉及到的范围都应该被包括到，无论是业务层，持久层，数据层等等。脑图里只是简单列出来了比较容易看到的网络层，应用层，数据层等。同时，DC应该符合单元化架构，在IDC级别也需要做到灾备。即前面提到的灾难管理。这里针对数据层的高可用简单说下，数据库本身有着MGR，MHA，PXC等模式去维护高可用。M-M和MGR其实和A-A是类似的。

• 可扩展性能够快速的通过增加计算资源动态满足业务量的增长。一般有垂直和水平两种方式。在现代大型架构中，负载均衡提供了很好的扩展性。具体参考下面的读书笔记。

• 安全性在此就不谈了，前面写了很多博客讲安全架构了。最近的一个感悟是，安全如果能从最初的DC设计到IAAS，PAAS平台的搭建过程，应该会更能满足安全内生(Security by Origin)的设计理念。

• 数据同步需要高可用，高可用的过程也需要数据同步。不过CAP理论而言，只能3选2。这里介绍了下一些数据同步的一些简单场景，例如服务发现，缓存同步，DB跨机房数据复制。

总结

无论是对外提供的业务还是内部服务都应该首先考虑不同业务的特点，然后尽可能的满足高可用。除此之外还需要思考对标准化，自动化，全链路的取舍。

原文始发于微信公众号（放之）：架构杂谈