架构误区系列 12：一切皆依赖云平台

最近，追随云计算的大趋势，公司的交易系统也在进行上云。但是，在上云的过程中，遇到了几个架构上的问题，从而引发了一些思考：在云原生和容器化的背景下，架构师是不是只需要关心上层的应用架构，而将下层的 Iaas 和 Paas 完全交给云计算厂商就可以了。

先简要陈述一下遇到的问题。

首先第一个是一个小容量站点的问题。我们的支付系统需要在印尼开展业务，而印尼是强监管数据不出境的国家，我们需要在印尼本地部署接入点。由于印尼的业务目前还在拓展阶段，TPS 基本上平时只有 1 左右，大促的时候会短时间达到两位数，所以我们在印尼部署的是满足高可用要求的最小化架构。这里我们就遇到过几个问题：

• 一个应用数据库的所有分片被云平台调度到同一台物理机上从而导致一台物理机故障引起超过 10%的下跌。

• 多个上下游应用的不同分片被云平台调度到了同一台物理机器上，导致一台物理机的故障引起超过 10%的下跌。

大家可以看出来，这个就是一个云平台规模和上面部署的应用规模都比较小的场景下，导致资源集中分布的问题。在大的云计算平台或者应用集群相对较大的场景下，这个问题的发生概率会大幅度减少。

第二个是大促的场景下如何应对短期大交易量。由于大促所需的资源数量和日常有近百倍的差距。所以，我们有两种选择：

1. 日常就按照大促的量进行部署；

2. 大促临时扩容。

两种选择有各自的优缺点。日常按照大促量进行部署的方案，能保证大促的时候有足够的资源可用，但是带来的问题就是成本的大幅度增加。大促临时扩容的方案，可以很好的控制成本，但是对于大促放大倍数较高的场景，需要承担大促申请不到资源的风险。

第三个就是最近香港阿里云的故障问题。我们目前在香港还没有很大的业务，相对较大的业务目前也没有上云。如果这个问题我们遇到，会不会导致我们核心的业务跌零，有没有成熟的高可用和容灾的预案。

所以，云原生、容器化、serverless 之后，架构师就只需要关注应用架构，对于 Iaas 和 Paas 就不再需要投入精力这个观点是不对的。

云服务是一种通用的服务，只能满足一般意义上的高可用架构需求，对于一些特殊的需求例如小站点需要我们自行关心。同时，我们在架构层面还需要考虑到公司和业务的特性，通过一些特殊的设计带来竞争力。例如大促如何更经济的扩容，离线和在线计算如何更节省成本等等。另外，如果我们的系统的高可用等级比云服务厂商能提供的四个九五个九还要高，那我们还需要应对云服务厂商服务不可用下的高可用课题。

首先，我们需要对我们的部署架构有一个清晰的数字化的视图，来应对云平台在服务器漂移或者云平台自身规模较小情况下容器分布过于集中导致我们的应用系统高可用等级下降的情况。在印尼站，我们是利用了阿里云的部署集——就是一个部署集的节点阿里云承诺会打散不会放在一个物理机上。我们可以将同一个逻辑库放入同一个部署集，从而杜绝不同分库在同一个物理服务器的情况。但是，阿里云的部署集在同一个可用区的节点数量有 20 个的限制。所以，对于上下游应用的不同数据库分片不能在同一个物理服务器，这个功能还是不能满足。只有通过不停的巡检才能发现和应对。其实，不管云平台有没有打散的能力，我们都需要对每一个节点所部署的容器和物理服务器有清晰的了解，并形成一个部署的数据库，通过不断的巡检分析有没有出现不合理的共物理机的情况，如果有，进行重新部署解决。

其次，对于大促扩容的场景，我们需要在尽量节省成本的基础上，对大促的资源有一个良好的保障。所以，我们在架构上首先需要考虑在离线混部的方案，在大促时将离线资源临时调拨给在线交易使用，这样既能在大促是预先规划好资源，又能在成本上不造成浪费。同时，我们也需要考虑大促的临时扩容，同时设计弹性扩容的架构，在大促后还能做到缩容量。这个后面有机会可以详细论述，计算资源扩容缩容比较简单，存储资源就相对复杂，需要在数据库分片路由上扩充能力。另外，考虑到临时扩容云平台资源不足的场景，我们还可能需要考虑将不同厂商的云服务整合成混合集群的方案。

最后，应对云平台的不稳定性，我们也需要有架构上的应对方案。第一，针对云平台可用性问题，我们需要难过在关键应用上增加应用级容灾。第二，针对云平台整体不可用的极端场景，如果我们不能忍受这个问题带来的业务连续性风险，就需要建设同城和异地容灾的能力，同时最好同城采购不同的云服务厂商的服务。

目前想到的是这三个架构点，肯定还有其他的点需要架构师重点关注。不论使用裸金属架构，还是用云服务；不管是公有云还是私有云，我们作为架构师都需要充分了解自己公司的业务特点和技术架构现状的前提下，进行有针对性的架构设计。通过架构给业务带来差异性和领先性，是一个优秀架构师的职责所在。