“ 上云，就是把已有系统直接迁移到云上那么简单吗？”
01
—
没有云的窘况
我们的核心系统是一套非自建系统，其新版本升级在2016年启动。
由于所有业务都在跑在旧版本，不能长时间停机。而且新版本的架构设计和对服务器的要求不一样，需要搭建一套新的服务器。
当时规划要把旧版本的所有业务迁移到这个新版本，而且计划两年后要上线的新客户也会落地在新版本，所以在服务器的架构设计和配置上，考虑了已有业务的增长和新客户的预估业务量，服务器的配置是相当给力的。
由于系统的核心逻辑都在存储过程里，对数据库性能要求高，数据库服务器采用了强悍的3 3 Oracle RAC（3台服务器的多活）的架构。我们戏称这套服务器架构是一辆“法拉利”跑车。
新版本系统的生产环境在2018年就绪，但由于业务计划的调整，有新的客户要插队，现有业务的迁移一直被搁置。2019年只迁移了其中一个业务量较少的地区的业务，2020年中，上线了一个“插队”的新客户。
到目前为止，我们监控看到该系统的服务器负荷还不到10%。我们估算，就算把已列入未来一年计划的两个新客户的业务量算上，到2021年底，服务器负荷应该低于30%。
而占大头的现有业务迁移，由于这两年不断有新客户“插队”，现在还没有具体的计划。
而明年，因为服务器目前使用的Oracle版本和硬件型号的维护期到期，我们又要投资更换部分服务器了。也就是说，这辆强悍的“法拉利”还没全力跑过，就要“大修”了。
这背后都是钱啊。这显然是一个巨大的浪费。除了业务计划不断变更和项目交付慢以外，缺乏弹性的基础设施也是罪魁祸首。
这套服务器架构是搭建在自建数据中心的，没有云能赋予的弹性，加上由于内部流程，新服务器上线生产环境需要差不多一年的时间，周期太长，我们只能依赖预测来提前规划服务器的架构设计和配置，这就不可避免地导致了要么浪费、要么不足的窘况。
02
—
瞎上云的窘况
兄弟团队负责的另一个核心非自建系统正在上云。和我们负责的系统一样，都是遗留的单体系统，在上云过程中卡壳了。
由于是单体系统，系统只能整体部署在单台服务器上，要满足其性能要求，需要高配置的服务器。但是我们知道，云的优势并不在于提供更强的服务器，而是通过水平扩展，在需要扩容时迅速获取更多的服务器来提供支撑。
从架构的角度，传统的架构需要一台更强的服务器，而云架构则通过多台配置相对不高的服务器来实现。
这里涉及到弹性伸缩的两个概念：
- 垂直扩展（Scale Up）——通过提升服务器的配置，如增加CPU、内存等资源；
- 水平扩展（Scale Out）——通过增加服务器来实现。
垂直扩展有几个问题：
- 增加硬件配置并不能得到处理能力的线性增长，比方说CPU核数从20个升级到40个，处理能力并不一定会增加一倍；
- 增加硬件配置是有上限的，并不能在一台服务器上无限增加CPU和内存；
- 单机配置越高，成本越高；
- 无法在不停机的情况下实现垂直扩展。
而水平扩展则可以是无限的，弹性非常大，而且由于每台服务器的配置并不需要很高，扩展成本可能比垂直扩展要低。
云的优势就在于水平扩展能力上，搭配负载均衡、监控和自动伸缩组设置，可以实现在业务高峰时自动分配更多的服务器做扩容，在业务低谷时自动释放服务器做收缩，更合理地分配资源和最大化成本效益。
由于单体系统只能作为一个整体部署在单台服务器上，特别是很多遗留系统的大部分逻辑都是通过存储过程来实现的，重度依赖数据库，很难通过水平扩展来提升性能，只能依赖高配服务器。
在云上，所有的服务器资源，包括服务器的品牌、型号和配置组合都被标准化和同构化。默认情况下，我们应该首选云提供的标准配置组合。
多数云也提供了通用型、计算优先型、内存优先型、存储优先型等各类资源，满足通用和特殊需求。
但如果这些标准组合仍不能满足需要，部分云厂商也会提供定制的异构服务器，但这样的话，云厂商也需要特别按需采购新的服务器，可以想象，周期和成本都会是问题，云的优势也被严重削弱，这种场景只是把云当成自建机房的简单替代品。
目前这个系统所需要的配置，就是我们选择的云厂商的标准组合里无法提供的，加上无法运用横向扩展，将很难享受到云所带来的好处。由于是非自建系统，由第三方购入并依赖第三方进行开发，我们无法改变其架构设计。
这种情况，乖乖地留在自建机房，也许是更好的选择。
以上两个例子说明，缺乏弹性的基础设施和陈旧的架构设计都是祸根。
03
—
云架构
今天，上云是一种潮流。诚然，云可以提供自建机房无法提供的经济、灵活、弹性，赋能交付团队和运维团队实现高效交付和运维。但要充分享受云所带来的好处，系统的架构也必须配合，需要满足所谓的云架构的要求。
前面提到，云的弹性是通过水平扩展实现的。如果系统架构是单体的，基本上很难享受云的好处。因此要充分享受云优势，系统架构设计应满足以下原则：
- 应用程序必须是无状态的，而且承载大部分逻辑
前面提到，云能提供的最大帮助，就是通过水平扩展来实现系统处理能力和计算资源的弹性伸缩。要满足水平扩展，运行的程序必须是无状态的。
什么叫无状态和有状态呢？
先说有状态吧，比较容易理解。数据库就是一个典型的有状态的代表。一旦有新的写入操作，不管是新增记录、修改记录还是删除记录，整个数据库的状态就和之前不一样了。
对于这样的单元，是无法进行自动伸缩的。因为在系统运行时，不断有写入操作，这个时候突然新增服务器，需要把数据库最新的状态——也就是所有数据都要同步到新的服务器上，这是一个很复杂而且耗时的过程，要保证所有节点的状态，也就是数据的一致性。
所谓无状态，就是不管被调用多少次、怎么被调用，其属性和结构都不会发生任何变化。
就像一个函数，同样的输入，不管被调用多少次，其输出都是一样的。无状态的程序，可以被立即部署和运行，不需要和其他程序进行任何的状态同步，也可以被随时销毁，不影响系统的任何功能。这是实现自动弹性伸缩的必要条件。
系统整体肯定是有状态的，但在设计上，我们应该让应用程序层保持无状态，把所有状态维护在数据库和共享存储中，实现无状态和有状态模块的分离。
一般典型的MVC设计的系统，都有应用程序层和数据库层，而且要求应用程序和数据库不能部署在同一台服务器上。
而数据库，特别是关系型数据库，即使部署在云数据库上，虽然可以随时调整配置或增减节点，但不能自动伸缩，调整过程需要中断服务。
这也要求系统设计上，要把大部分的逻辑放在应用程序层。像前面提到的那种大部分逻辑通过存储过程实现、重度依赖数据库的系统设计同样无法享受自动弹性伸缩。
最近流行的Serverless也是要求运行的程序是无状态的。
- 尽可能拆分
把单体系统拆分成服务化或微服务架构。
单体系统，虽然内部有模块化设计，但由于被封装成一个整体，只能整体部署在单台服务器上，运行起来会变成了一个大的黑盒子。
通过架构拆分，可以实现我经常说的把复杂问题降维成繁杂问题（对这个话题感兴趣的，可以参照文末的推荐文章）。系统被拆分成若干个可独立部署、运行的服务或微服务后，每个服务会变得相对简单。
大黑盒子，也变成了一个个可见的单元。所谓看见的力量，人对于可见的东西，掌控感更强。
由于被部署到独立的服务器上，我们便可以通过架构手段来解决问题，我们可以根据不同服务的负载，分别进行计算资源的配置，并为高负载的服务进行水平扩展。
当然，通过这样的拆分，服务器的数量会激增，整个系统变成了一个繁杂的架构。而云恰恰是为繁杂架构而生的，通过自动化、监控、镜像等工具和手段，赋能我们管理繁杂架构。
- 异步化
单体系统被拆分成服务、微服务架构后，各服务间的数据交互或调用，则可以考虑异步化的手段。
由于不同服务的时效性和所需要的处理时间是不一样，耦合在一起或同步调用，必然会互相拖累。
比方说系统是一个信用卡交易系统。遇到购物节这样的交易高峰，核心交易服务必须要始终保持实时响应，但是交易通知、积分登记等服务，实时性要求就没那么高了。
我们可以把架构设计成：核心交易、交易通知和积分是三个独立的服务。核心交易服务完成交易后，通过MQ这类的消息队列把交易结果消息发送到通知服务和积分服务。这样，核心交易服务只需要关心和完成自己的交易流程，通知服务和积分服务会在收到消息后自动完成相应的服务，消息队列会保障每条消息被完整地消费，核心交易服务也不需要等待通知服务和积分服务的结果。
这样的异步化设计实现了充分的解耦，还能实现削峰填谷的作用。
如果整体的计算资源是有限的，当交易量巨大时，可以把更多资源分配给核心交易服务，减少分配给实时性要求不高的通知服务和积分服务的资源，通过后两者的服务降级，保障核心交易服务的实时响应。
在交易高峰过后，又可以把原来分配给核心交易服务的资源归还给通知服务和积分服务，帮助它们更快地处理积压的消息。
所有非实时、不需要同步的服务都可以通过异步化来交互和调用。
04
—
总结
云可以提供自建机房无法提供的经济、灵活、弹性，赋能交付团队和运维团队实现高效交付和运维。
但云并不是自建机房的简单替代者，要充分享受云所带来的好处，系统的架构必须满足应用程序层无状态、分布式和异步化的云架构的要求。
觉得文章不错，顺手点个“点赞”、“在看”或转发给朋友们吧。
