共计 2888 个字符，预计需要花费 8 分钟才能阅读完成。
前言
随着 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 是否要满足一些非凡场景
- 第三方服务是否有特殊要求
- 在这个架构下咱们是否能动静横向和纵向扩容
总结
心愿下面的一些分享能帮忙大家在设计云基础设施架构的时候提供一些参考。
这样的架构设计波及的货色是十分广的，不同的我的项目也会有不同的设计要求。
因而，最终设计肯定要联合我的项目的理论状况，满足了业务须要就是好的设计。
记住一句话，没有正确的设计，只有刚好实用的设计。
