刘华：上云后，你的架构设计可以更飞





本篇文章作为弹性便是一切的姊妹篇，以某电商的痛点入手，介绍如何通过迁移到云上解决各种问题，并给出了架构设计的调整思路。



某服装电商公司的网站系统是搭建在自建机房里的。



这个网站可以让用户通过网页端或手机端建立和管理自己行头，并让用户、设计师和零售商之间建立社交网络，使三者形成互动。



该网站的架构是有一个前端服务，后台的服务被拆分成若干个微服务，数据库是MySQL，除了进行日常的交易数据处理（OLTP），业务也需要进行实时的数据分析（OLAP），形成各种报表，以观测销售数据、用户行为等。



他们遇到了几个问题：



1. 由于业务增长迅猛，他们的服务器数量从几台暴增到几十台，但仍未能满足业务增长的需要；

2. 业务量在每周不同日子，每天不同时点是有波动的，低谷时的业务量是高峰时的十分之一不到，导致高峰时服务器资源紧张，低谷时又有大量服务器空闲；

3. 业务已经拓展到海外，海外用户普遍反映访问速度较慢，特别是视频和图片；

4. 由于采购新的服务器周期长，配置新服务器也需要时间和人力，导致系统变更速度受到拖累，无法快速满足用户的新需求；

5. 由于服务器昂贵，配置选择不多，他们往往把几类不同的微服务集中部署到一台服务器上，无法实现微服务架构设计所设想的故障隔离和弹性伸缩，也增加了系统间不必要的依赖，造成运维困难。

6. 由于软件价格昂贵，中间件和数据库的选项不多，所有的数据操作，不管是交易型数据处理（OLTP）还是数据分析（OLAP），都集中在一个关系型数据库上，导致该数据库运行压力大，系统性能也大打折扣。



于是他们想到了云。



我们来看看云能怎样解决这几个问题：



1. 在云上，有几乎无限的计算资源可以租用；

2. 只要系统架构设计得当，可以完美实现弹性伸缩，既能满足业务增长的扩容需要，又能在业务低谷时释放资源，节约费用；

3. 大型公有云商都提供全球部署，可以把系统部署到不同大洲的区域，通过全球负载均衡让用户可以就近反映，也会提供CDN服务加速视频、图片等静态内容的下载；

4. 在云上获取新的计算资源都是几分钟的事情，可以实现按需即用；

5. 云上，服务器的种类、配置选择众多；

6. 更重要的是，除了提供服务器、存储、网络这些基础设施服务外，云还提供了托管数据库、对象存储、容器运行环境、应用运行环境、大数据处理、机器学习等平台服务，除了选择多，也能大大减少运维负担。



最后两点尤为关键，它为我们的系统解决方案提供更多的选项。



过去，在自建机房，服务器的数量和配置选择有限，中间件、数据库等软件的选择也是有限的，我们在技术选型上不得不做各种妥协，甚至把不应该部署在一起的模块和服务迁就在一起，两头不到岸。



但在云上，我们在技术选型则自由得多。



以数据库为例，除了关系型数据库，还有各种类型的NoSQL数据库、针对数据分析（OLAP）优化的数据库等。为交易型数据处理（OLTP）配置关系型数据库，为数据分析（OLAP）配置相应的服务，既互不干扰，又能把各自的特性和性能发挥到极致。



在部署上，我们可以把每一个微服务部署到独立的服务器或集群中，从一台高配置服务器集中部署多个系统的方式转换成多台低配置服务器，每台服务器只独立部署和运行一个独立系统和服务，完美实现微服务架构设计所追求的故障隔离和弹性伸缩。云也提供了管理繁杂架构的可视化、监控、链路跟踪、熔断、日志等的服务，大大降低运维管理的难度。



除此之外，云的弹性伸缩和按需付费天然适合像大数据处理和机器学习这些在运算时突然需要大量算力，但运算后又不需要这些算力的场景，我们无法想象要为这些场景专门采购服务器需要多大的成本、多长的周期和造成多大的浪费。



而且，云除了为这些场景提供算力外，也把常用的处理流程、算法、语言和工具打包成开箱即用的平台服务，大大节约开发成本。



前文提到的电商网站系统，在迁移到云上的过程中，充分理解了云提供了哪些服务和选项，并对系统的架构和设计进行相应的调整。它的架构设计调整为：



1. 根据业务开拓的情况，分别在亚洲、欧洲和北美三个区域部署了系统，配置了全球负载均衡和CDN实现用户就近访问，大大提升每个区域用户的访问速度；

2. 所有微服务都通过容器部署在云托管的Kubernetes集群服务上，简化了部署过程，并实现了自动弹性伸缩；

3. 交易型数据处理（OLTP）通过云托管的关系型数据库实现，直接实现了多点部署，并在不需要修改代码的情况下实现了读写分离；

4. 数据分析（OLAP）通过云托管的分析型数据库实现，能在数秒处理TB级的数据；

5. 监控、日志查询、报警等全部依托于云的服务，可以集中处理架构中所有服务的运维工作；

6. 开始考虑借助云的大数据处理服务和机器学习服务，实现智能推荐和广告精准投放。



通过这次迁移，该公司再不需要担心业务量激增、业务范围拓展所带来的“成长的烦恼”，公司的发展也有了更多的可能性。开发团队也能轻易搭建新的测试环境，加快开发和测试的速度。



当然，该公司也没有把全部“赌注”都压在一个云厂商上，他们还是保留了部分自建机房的资源，作为灾备环境，为将来退出某个云厂商留了后路。



觉得文章不错，顺手转发给朋友们吧。



分割线 卡通

关于作者

• 敏捷、精益、DevOps专家

• 公众号“敏于思 捷于行”博主

• 精通极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发、DevOps工具栈

• 曾在GDevOps、DevOpsDays Meetup、中国软件技术大会、ArchSummit等论坛发表主题演讲

• 阿里云、谷歌云认证架构师

• 著有《猎豹行动：硝烟中的敏捷转型之旅》一书和专栏《软件交付那些事儿》







关注公众号看其他原创作品

敏于思 捷于行 

坚持原创高质量软件交付相关文章



觉得好看，转发给朋友们，欢迎你留言。