前言
随着AWS、阿里云、Azure、腾讯云等公有云的蓬勃发展，越来越多的企业开始在考虑上公有云了。
这些年做架构咨询，发现很多传统的公司在基础设施上云的过程中没有明确的设计思路，只是一通购买云产品，然后使用云产品，认为这样就是上云了。
但其实，如果没有一个很好的云基础设施架构设计，会使后续的云使用变得难以维护，达不到预期的效果，同时成本上升。
这篇文章里面，我会分享一些过去项目中的公有云设计经验和思路，给大家提供一些基于微服务的场景下如何设计云基础设施架构的参考。其中这里的云指的是如阿里云，AWS的公有云。
为什么要上云
上云的好处或价值在各大文章里面已经说得非常多了。
我这里也敷衍的列举几个好处和价值吧。
- 降低成本
- 可伸缩性
- 专业的运维
- 速度
降低成本
降低成本主要是降低了两类成本。
- 公司不再需要招聘专业的运维人员专门负责维护服务器。（大型公司除外，他们通常需要大量的运维人员统一维护全公司的云资产或者自建云计算）
- 公司不再需要专门的人员来针对运维开发各类工具，如今常见的云计算平台都包含丰富的功能，以及完善的售后体系。
可伸缩性
可伸缩是传统的服务器无法做到的，这也正是如今云计算越来越火的一个很大的原因。
我们可以根据业务的需要，扩展服务性能，不仅如此，而且还能做到缩小服务性能，以节约成本。
专业的运维
上云之后不是没有运维了，而是把运维交给了云计算平台的专业的人来做了。而你只需要关心如何基于这些云基础设施构建自己的产品了。
速度
速度是指各方面的速度都提升了。比如，你只需要花1分钟时间就能创建一台新的服务器，你只需要花1分钟时间就能扩容某个服务。由于减少了各种搭建配置时间，开发时间因此也缩短了。缩短了试验和测试的时间，更快的为客户提供可用性。
云基础设施架构成熟度评估
那么上云之后我们如何知道我们的云基础设施架构是足够优秀的呢？
这里就需要有一套云基础设施架构成熟度评估模型。
我根据这些年的架构咨询工作，结合多个项目总结了这套云基础设施架构成熟度评估模型。它
主要分为8个模型，5种等级。
这8个模型是：
- 可伸缩性 - 云基础设施能根据业务需要自由伸缩
- 可复制性 - 云基础设施能根据业务需要快速复制
- 可恢复性 - 云基础设施挂了之后能自动或快速恢复
- 可用性 - 云基础设施的设计能保证服务的高可用性
- 安全性 - 云基础设施的设计能有非常高的安全设计
- 可量化管理 - 云基础设施应该可以被量化管理以优化成本
- 可维护性 - 云基础设施应该具有更简单的可维护性
- 可组合性 - ****云基础设施会根据业务需要组合使用
这5种等级是：
- 原始级 - 完全没有使用云基础设施
- 基础级 - 尝试了一些基本的云基础设施
- 标准级 - 所有基础设施都上云了
- 成熟级 - 所有基础设施都上云了并且掌握云基础设施架构的最佳实践
- 领先级 - 自建云计算
结合上面的模型，我们就可以得出如下的打分。
基于这个打分，我们就可以得到如下的评估图。
那么接下来，我们就把这个架构设计展开来说一说。
主要说一说VPC设计，访问控制设计，安全设计和数据库设计。
VPC设计
VPC全称是Virtual Private Cloud，是云上的一个逻辑隔离的专有网络。
使用VPC主要是为了安全隔离，把不同的环境隔离开来。一是避免环境污染，二是保障安全性。
因此，如下图所示，通常一个企业都会设计以下几个VPC环境：
- 产品环境
- 测试环境
- 开发环境
- UAT环境
产品环境是我们线上所有产品运行的VPC环境，只有用户能接触到的一个环境。
测试环境是做测试用的，也是大部分公司开发人员和测试人员能接触的一个环境。
开发环境则是日常工作所在的环境，它通常与办公网络是连通的，这里会放我们的git，pipeline，镜像仓库，制品库等。
UAT环境通常是给客户做验证的，比如上线前，需要让客户去验证是否符合预期了，这个环境之所以不能使用测试环境是因为通常客户需要导入一些真实数据做测试，需要保证UAT环境的干净。
另外，如果有多地域部署系统的要求，就需要使用多个VPC，因为VPC是地域级别的资源，是不能跨地域的。
访问控制设计
我们的云资源不是对所有人开放的，特别是对于产品环境的访问控制应该尤其严格，一是防止内部人的误操作，二是防止黑客的入侵。
但我在很多客户那里都遇到过，他们没有任何访问控制设计，所有的开发人员都共用一个或几个账号。这是非常危险的使用方式，不利于管理，也有诸多风险。
现在的公用云都有访问控制功能，通常叫做Resource Access Management。
访问控制的设计主要从下面几个纬度去考虑：
- 用户管理
- 用户分为：真实用户，虚拟用户
- 真实用户就是那些真实的人。比如员工和用户。
- 虚拟用户就是分配给某个系统使用的账号。比如某系统需要有上传图片的权限。
- 读写分离
- 通常有的人只应该拥有只读权限。
- 有的提供给系统的账号应该只有只读权限。
- 比如，访问对象存储的用户头像的账号应该只有只读权限。
- 管理员或者上传图片功能需要拥有写入权限。
- 角色管理
- 不同的人可能都是同一个角色。
- 同一个人可能拥有不同角色。
- 角色决定了我们拥有哪些权限集。
其次就是，云基础设施的访问控制是否需要和企业内部自己的单点登录集成，也是需要考虑的设计。
总结一下就是，访问控制应该遵循最小权限原则，才能最大限度的保证系统的安全性。
安全设计
大部分人的误区是，我已经用云了，再买个防火墙什么的，就很安全了。
但其实公有云是完全暴露在互联网的，因此也需要有完善的安全设计才能保证云基础设施的安全。
把该隐藏的隐藏进私网里面，只暴露最少的信息。
基础设施的安全设计主要包含几个方面：
- 网络安全
- 包括传输安全，比如数据如何加密传输
- 网络是否暴露
- 网络设计是否合理
- 数据安全
- 数据是否被足够的保护了
- 数据是否暴露在了外面
- 权限安全
- 是否按照最小权限设计的
- 是否读写权限分离了
总结一下，设计的时候需要遵循两个原则：
- 零信任网络
- 最小权限设计
数据库设计
这里主要是涉及到数据库的高可用和高性能的设计问题。
高可用方案通常有3种方向：
- 主备架构
- 通常会有多节点，不同点节点会在不同的可用区
- 容灾
- 容灾主要分为异地容灾和同城容灾
- 备份恢复
- 数据库挂了之后如何快速自动恢复
- 恢复期间的数据丢失如何找回
这里的高性能设计不包括分库分表相关的设计，因为这只是关于基础设施的架构设计。
通常需要考虑：
- 如何弹性扩容？
- 是否需要读写分离？
- 读写分离后数据的一致性如何保证？
- 根据业务场景，需要多少读实例？
- 缓存如何设计
下面是一个大概的高性能高可用数据库架构的样子，供大家参考。
云基础设施架构设计
总结起来，一个常见的基于微服务的云基础架构设计，大概就长下图的样子。
我们在设计的时候可能需要考虑的远不止下图的中的东西。
比如我们得考虑：
- 多个VPC如何通信
- 集群如何编排
- 数据库选型
- 日志收集用什么工具才能易于收集易于搜索
- 运维监控用什么工具才能全面监控并能智能警报
- MQ是否要满足一些特殊场景
- 第三方服务是否有特殊要求
- 在这个架构下我们是否能动态横向和纵向扩容
总结
希望上面的一些分享能帮助大家在设计云基础设施架构的时候提供一些参考。
这样的架构设计涉及的东西是非常广的，不同的项目也会有不同的设计要求。
因此，最终设计一定要结合项目的实际情况，满足了业务需要就是好的设计。
记住一句话，没有正确的设计，只有刚好适用的设计。