云架构的思考2–云上架构

目录

• 1 云架构考虑因素
• 2 云架构设计步骤
• • 2.1 梳理需求
  • • 2.1.1 功能需求
    • 2.1.2 非功能需求
  • 2.2 业务架构
  • 2.3 设定合理预期
  • 2.4 确认应用程序迁移云端、托管或者重新编写（可选）
  • 2.5 选择云服务模式和部署模式
  • • 2.5.1 选择云服务模式
    • 2.5.2 选择部署模式
    • 2.5.3 格外的案例
  • 2.6 选择云厂商
  • 2.7 日志、监控、审计
  • • 2.7.1 日志
    • 2.7.2 监控
    • 2.7.3 审计
  • 2.8 安全、SLA
  • • 2.8.1 安全
    • 2.8.2 SLA
  • 2.9 选择云产品
  • 2.10 成本控制
• 3 云架构的一些思考

前面一章我们了解了云计算的特点、服务模式、部署模式，现在这一章我们主要讲基于云上做架构设计。架构设计主要为了符合我们的需求，同时需要具有一定的合理性和前瞻性。本章基于个人做过的不同项目云架构过程总结，包括执行步骤以及经验总结。

1 云架构考虑因素

云架构考虑的因素与不上云的架构考虑因素没有什么太大区别，这些都是架构基本要考虑的问题：

• 业务架构：业务是第一需求，所以云上架构最先关注是业务需求
• 为什么上云：要理清楚企业为什么上云，是传统架构解决不了的问题？是云架构带来新的好处？
• 确定架构的相关参与者（包括组织中的人或者系统）
• 技术需求和非功能需求：包括性能、灵活、可扩展、高可用、安全等等
• 产品交付日期：产品交付时间也是很关键的因素，特别是紧迫和非紧迫时考虑的架构方案完全不同
• 成本预算：成本预算在选择是否上云也是一个重要考虑方案，同时成本不单单包括单次费用，同时还包括后续维护，云付费方式和传统的数据中心付费方式完全不一样
• 组织结构能力：本身公司的IT能力和组织架构变革也能决定你对架构设计的选择
• 能承担风险：风险承担能力决定包括数据安全、可用性等非功能需求
• 战略需求：公司的战略有时候是一个决定性的因素，可能目前带不来看得见的收益，但是在未来有更好的扩展性和前瞻性

2 云架构设计步骤

云架构的设计流程总结为2.1-2.10等10个步骤。

2.1 梳理需求

这里的需求包括功能需求和非功能需求。这里列举一些常见功能需求和非功能需求考虑点

2.1.1 功能需求

• 本身功能的业务需求
• 功能是核心功能（关乎你企业生存的业务功能）、辅助功能（如企业办公系统）还是基础组件功能（如缓存、消息中间等）
• 功能数据容量大小
• 功能数据是否涉及较高保密要求
• 功能是否涉及合规要求

2.1.2 非功能需求

• 交付时间长短
• 成本预算大小
• 能承担多大不可用风险（高可用）
• 是否要求具备高性能
• 是否要求具备高扩展性

2.2 业务架构

为什么要画出业务架构，再次强调技术就是为了实现业务，因为云架构往往是多种解决方案的集合，有可能你会采用混合云搭配，IaaS、PaaS和SaaS搭配，因此只有你画出业务架构，再将业务每个模块梳理清楚其功能需求和非功能需求等因素之后，你才能决定哪些模块需要什么样的解决方案。还要就是将整个业务列出来相互关系是有一个更高视角看待你的业务。以下是一个常用的业务架构图仅供参考：

• 一般会涉及多端访问，那么采用统一个API是最好的方式
• 业务功能会被划分多个模块或者服务，其中有一些是基础功能/服务
• 可能还存在一些其它企业内部系统

注意：这里只是一个示例，业务架构图不同人有不同划分，但是这里强调业务架构图就是让你理清楚你要实现的整体业务需求是如何组合以及之间的关联是什么

2.3 设定合理预期

之前说了上云的决定往往是听到某些成功案例，但是不要将个例当做标准，这样往往就会出现不切实际的期望，因此要设定合理的预期。下面列举一些不切实际的期望：

• 与某成功产品一模一样的效果。有时候哪怕让该产品重新做一遍都不一定有一样的效果，成功产品之所以成功这其中往往是产品本身的能力，并非都是云的功劳，云有时候是锦上添花的作用。建议：设定合理预期是云能给你产品带来什么新特性或者竞争优势，而不是设定上云产品就能成功。
• 只需要更少量IT人员就能完成，并维护。这也是往往听到的是成功之后的效果，但是在整个过程中人员曲线往往是先上升后下降、再稳定的。没有一开始上来就规划只需要多少人，因为往往你的原先IT团队就没有云经验，因此这时候你需要引入有云经验的人，同时也要保留原来的IT团队来对接和维护原先云下系统。建议：按照步骤合理规划人员，而不是朝着目标定死。
• 成本一定会大幅下降。成本比较多内容，在架构中我也会单独一个点来讲述如何控制云上架构成本。成本下降是需要做一定优化同时还不能增加太多太大的功能情况下才有可能实现，建议：不要一开始就定成本能节省多少，而是把节省成本放在架构的约束条件中。
• 过高的容灾要求，一听到云上多区域、多可用区，就会认为云上的容灾有多么容易。确实云上的容灾操作会比你自身建立数据中心来的更加容易，但是容灾要求需要根据你自身的需求决定，因为需要的RPO和RTO越低，成本会越高。建议：按照自身要求对各个业务模块定详细的容灾要求。
• 过高的安全要求，和容灾一样，云上很多现场的SaaS安全产品，很容易就将其一一购买使用，最终导致成本过高。我们要知道云上会提供免费的基础安全防范，但是对于高防一般都要收费。建议：梳理自身安全需求，对不同内容选择不同的安全措施，一定要熟悉不同安全产品的限额等参数，这样在选择时就得心应手。

2.4 确认应用程序迁移云端、托管或者重新编写（可选）

这部分是针对已经存在自身的数据中心情况，如果是一个新的产品确定要上云，则可以忽略这一步。在讲对云的误解第一条，就是将系统搬到云上部署就算是上云，但实际上有可能你就使用几台ECS按照你线下部署的方式部署，这样并没有利用到云的优势，因此只能算是部署在云上，而非真正上云。在很多公司都会存在大大小小一堆系统，那么当希望将业务上云的时候，其实并不是所有系统都必须上云（除了公司硬性要求上云外的因素），这里列举一下判断是否上云需要的几个因素：

• 系统运行年限：该系统是多少年前的系统，如果存在时间过于久远，可能不适合直接迁移，基本上要重写。
• 熟悉系统内部的维护人员是否还在：过久的系统存在可能连懂得系统内部的人员都没有
• 该系统迁移是否带来收益
• 系统迁移云成本改造成本
• 系统是否为横向扩展，这一点非常重要，因为老系统大部分都是垂直扩展（就是加CPU、内存等），具备横向扩展的系统才是云上的一大特点
• 系统是否为无服务状态，无服务状态也是最大化利用云特点的一个必需条件。假如不具备条件，则可能就是简单部署在云上。

可能考虑的因素不止上面的内容，但是也能涵盖大部分，那么如果分析完旧系统，加入不具备上云，那么有以下3种方案选择：

• 云上托管：也就是说的直接部署在云上，但是仅仅部署在云上，利用云的基础设施（考虑维护人员问题）
• 选择替换成熟SaaS：利用已有的成熟SaaS来替换原先系统（考虑旧数据问题）
• 重新编写：完全重新编写让其适合于云（成本过高，一般不会采取）

2.5 选择云服务模式和部署模式

在2.3中，梳理完系统的业务结构，那么就可以按照服务甚至功能来决定云服务模式和部署架构。

2.5.1 选择云服务模式

在上一章中，我们讲了3种云服务模式的优缺点，这里我们将其梳理为我们选择它们的标准，这样我们就能按照需求约束来选择什么样的云服务模式：

可能标准有时候过于笼统，这里举一些具体例子帮大家理解：

• 某一服务有高并发、高可用的需求，优选选择IaaS，因为IaaS对性能和扩展性掌控力更足，PaaS由于厂商可能会限额或者PaaS出现问题只能等厂商修复，可能达不到高并发和高可用的需求
• 底层共用的服务，一般都会选择IaaS厂商提供的服务
• 特殊要求，可能PaaS提供商无法实现的要求，可以使用IaaS自己来实现
• 一般流量和存储量以及用户较低的服务选择PaaS，因为哪怕PaaS限额也能达到要求并且不用自身维护PaaS层
• 一般没有高并发、高可用的服务选择PaaS，即便厂商的PaaS无法运行，损失可控
• 可以一定降低开发工作量可以选择PaaS
• 公用服务，有别于底层共用服务，这里可能指K8S、消息队列等中间件
• 非核心业务的系统，如CRM、ERP、审计、人力资源等企业应用
• 很成熟的解决方案SaaS产品，比如人脸识别、支付等
• 公用服务，这里是SaaS层产品，且它为非核心

2.5.2 选择部署模式

在上一章中，我们讲了4种云部署模式的优缺点和适用场景，其实还有很多其它的部署模式，这里就只列举比较常见的4种，这里就不再累述。

2.5.3 格外的案例

在上云上面，除了规规矩矩的上云之外，其实很多公司发现了云的一些特点，使用了一些不一样的云服务模式和部署方式，这里可以供参考：

• 数据挖掘：之前机器学习需要大量的算力，但是机器学习可能只用几次就不再使用，那么购买大量机器会造成浪费，这里是在云上训练是一种非常好的方案
• 快速试错环境：由于云上是一个简单且快速的搭建过程，那么很好的作为一个快速测试一个流程或试错某个架构的方案。
• 云上云下配合：利用云提供格外的能力应付突增流量，正常时只是云下的服务，但需要某个特别短暂且高流量的活动时，可以选择云上+云上，这样用完之后可以立即释放云上资源，从而节省成本。
• 归档/存储：利用云存储成本较低的方案做备份，或者利用云上某些成熟存储产品作为存储。

2.6 选择云厂商

很多时候选择云厂商时，都是凭着一时喜好，可能是团队熟悉、可能是架构师熟悉，但是没有对云厂商有过一个比较正式的选择。那么云厂商是什么时候选择呢？其实之所以将“选择云厂商”放在这里并不是要里面敲定云厂商，而是从这一步开始就要考虑云厂商选择。意味着云服务模式和云部署模式敲定之后，可以初步参照自身需求选择对应的云厂商，同时在后续日志、监控、审计、安全、SLA等方面都要考虑云厂商问题，有时候甚至考虑多厂商做容灾。这里要强调的是：云厂商的选择也是要考虑进去，而不能凭一时喜好决定。

2.7 日志、监控、审计

2.7.1 日志

日志在我们任何数据中心都非常常见，无论是应用的日志、基础设施的日志等都是我们排除故障的选择。那么日志的作用如下：

• 故障排除：通过日志排除问题
• 审计：通过审计识别安全问题、权限滥用问题等非常重要，同时审计也是一些行为操作必须的日志。
• 监控：要完成自动化监控，那么日志是少不了的应用，比如监控CPU使用率自动伸缩等等场景
• 安全：识别不寻常的操作行为，是预防性安全的基本需求

那么云上日志设计有什么需要注意的呢？首先云上的应用日志由于可能自动伸缩，存储在本地的日志不像以前一样会存在。其次云上的基础设施日志也是有标准化接口采集，不需要自身手动增加。最后云上日志可能很多样化。我们需要做到几方面的内容：

• 统一管理日志：自建隔离存储区域存储日志或者使用成熟SaaS产品
• 日志格式化统一规范：不同应用有不同的日志格式，最后采集到却发现很难查询，就无法应用，因此使用统一格式非常重要：统一错误代码、应用名称、机器IP、机器名称、具体功能操作等。

2.7.2 监控

2.7.1日志这一小节说了日志的目的之一就是监控，那么监控首先分为主动监控和被动监控：

• 主动监控：在故障没有发生的时候，提前报警并自动解决问题
• 被动监控：在故障发生时报警，并且手动解决问题
  那么最好的当然是主动监控，在云上的监控与本身云具备的伸缩弹性、自动编排等功能，可以比较方便做到主动监控，因此建议在云上最好使用主动监控保持高可用性，下面列举不同类别的监控，只是提供一个参考：

这里强调一下监控指标是对应业务的可用性，因此也要跟业务对上，并且尽量采用主动监控

2.7.3 审计

2.7.1日志这一小节说了日志的目的之一就是审计，那么云上审计有哪些特点：

• 审计需要依赖云供应商，云供应商需要有一些合规证明
• 云供应商基础设施合规，应用层面的需要自己匹配法规

审计步骤：

• 基于客户和行业需要理清所有的适用法规
• 在产品路线图中创建出审计专用的工作流（数据管理、安全管理、集中登录、SLA管理、监控、灾难恢复、系统开发生命周期、运营和支持、组织变革管理）
• 搭建之前就将审计要求考虑进去，成本会比较低
• 公司规模和阶段也是考虑因素，如果是初创则审计可能不是考虑重点

2.8 安全、SLA

2.8.1 安全

2.7.1日志这一小节说了日志的目的之一就是安全。安全这个方面设计内容比较广泛，而云上就更加复杂，因为你需要与云供应商一起负责，而非直接丢给云供应商或者自己负责。那么云架构上安全需要梳理出负责界定，对于后续步骤以及出现问题解决方案的实施都是至关重要，那么不同云服务模式，云安全的责任如何界定：

实施安全管理需要一定的策略模式，下面列举3种方式

• 集中化：将一组安全控制、流程、策略和服务进行合并，减少需要管理和实施安全功能的地方。（单点登录）
• 标准化：接入行业标准的认证，比如OAuth和OpenID等
• 自动化：自动化接入安全

实施云安全步骤流程：保护->检测->预防
实施云安全的关注点：

• 策略实施：通过可配置的方式将规则与应用解耦
• 加密：传输加密和存储加密；
• 密钥管理：不以明文存储密钥；不在代码中自己引用密钥；密钥定时轮换；
• 网页安全：使用web框架+CSP提供扫描
• API管理：避免使用密码而是使用密钥；避免会话和会话状态；确保产品没有调试信息
• 补丁管理：定时自动化打补丁；必须可以回滚；
• 日志：不需要再强调了，日志是云安全的基础之一
• 监控：监控也是云安全采取主动防御的基础之一
• 审计：审计本身就审计安全审计

2.8.2 SLA

SLA的基础可以参考我之前写过的一篇博客：《稳定性建设落地实践》。这里主要讲一下在云上的SLA的一些影响因素和特殊性

影响因素：

• 消费者和企业客户
• 付费用户和非付费用户
• 受监管行业和不受监管行业
• 匿名和身份认证
• 服务的重要程度
• 不同模块的SLA程度不一致
• 消费者的期望

特殊性：

• 责任界定：因为需要搭建在云厂商的云上面，那么SLA需要界定负责的界限
• 了解云上不同产品及解决方案的SLA
• 除了原先的SLA要求，也要设定关注云厂商的SLA，定期订阅云厂商发布的稳定性报告
• 检查一些审计证书，比如：SSAE、HIPAA等

注意：虽然云厂商都会对其产品提供一些SLA的保障，但是如果出现超出SLA范围的故障，目前对于补偿或者赔偿方案还在探索中。

2.9 选择云产品

即便选定了某一个云厂商，架构方案也敲定了，但是还需要确认云产品，因为在同一个云厂商上面，实现同一个功能可能有不同的解决方案，这一部分如果展开讲的话，有点像AWS的SAP考试或者阿里云的ACE考试一样，一时半会讲不完。我这里通过几个常见的类别做一下举例，具体的还需要对云厂商的产品有详细了解。

• 首先还是通过云服务模式确定大体方向：基于IaaS的自建；基于PaaS快速部署；基于SaaS全托管。
• 计算资源：比如AWS的ECS或者阿里云的EC2，都有不同规格簇（CPU、GPU、内存等参数不一样，使用场景不一样），你需要根据业务选择符合自身的规格簇
• 存储资源：数据存储主要包括：块存储、对象存储和文件存储。当然在更上面一层可能你要考虑具体产品，比如使用关系型数据库、文档数据库、对象存储数据库等
• 网络资源：网络是要提前规划的，因为云上网络基本上都是VPC方式，也就是虚拟网络，可以按照你想要的方式规划。你需要考虑如何划分不同子网、对外网络、对本地数据中心网络等方式，选择弹性IP、NAT等不同产品也是你需要考虑的
• 中间件：比如MQ、编排工具、监管工具等，这些也有不同的选择，当然云上很多产品都是原先非云上产品也存在的，比如MQ，也同样会有kafka、rabbitMQ等，但是云厂商本身也会有自己的MQ，这些都需要你做选择。一般有3种选择，第一是基于IaaS自建；第二使用云厂商托管的；第三使用云厂商自研产品。
• 安全：你需要考虑加密、密钥管理、HTTPS、安全证书、漏洞检测、预防攻击等方方面面，因此在选择安全产品和设计安全解决方案，也可以根据云厂商的一些成功案例。

当然还有很多方方面面的内容，这里就不在累述了，我建议可以去考一下AWS的SAP考试或者阿里云的ACE考试，里面基本上都是根据实际场景要求给出一些合理的解决方案，另外也可以推荐看一些书或者看云厂商解决方案例子，里面会讲解一些常规通用的云上设计方案。如果有时间的话，我也会写一篇云上通用的设计模式吧。

2.10 成本控制

之前讲过上云误会之一就是上云一定能减少成本，但是实际上，能否减少成本需要具体情况具体分析。为什么把成本这一部分单独列出来，其中比如AWS的SAP考试中原先是有成本控制这一个单独的章节，但是最新的版本却将其去除了。但你看很多人说的一样，虽然没有独立成为一个章节，但是其实只是将其打散到其它章节里面。我认为这样做是正确的，因为成本本身就是各个解决方案需要考虑的重要因素之一，因此没有所谓设计后才看成本，而是在设计时就要看成本。这里单独列出来，只是想说一些实践中成本管理的通用方法：

• 改变成本管理方式：我们知道云上的计费方式往往是按量按需计费的，而传统数据中心可能是一次性支出。在这样一种转变下，需要你对成本的管理方式作出一些改变，不然你会经常出现某几个月费用不受控制。
• 统一成本管理：无论哪个云厂商，都会提供统一的费用管理工具，而且往往是免费的。在这个统一成本管理，你可以按照标签化管理不同分类成本，你可以控制某些资源的总体成本，你可以设置预警等等。这里想说的是在云上，一定要使用统一成本管理工具来管理你的整体成本。
• 标签化管理：在云上产品基本上都可以自定义打标签，通过不同标签，你可以按部门、按你自身财务分类、按团队等方式来标签化你的资源，这样有一个好处就是你最终在同一个成本管理中心可以看看你的成本哪些地方花费的多、哪些地方花费不合理等等。所以要善于使用标签化管理资源。
• 成本监控：成本监控就是预警，你可以设置某些成本预警规则，这样在成本达到某些预警值时，采取一些控制方案，以避免出现成本超出预期。
• 控制大小：云上的特点之一就是弹性，但是弹性会带来一个问题就是无限增长，有时候无意间的无限增长带来一个问题就是成本剧增。那么建议在使用自动伸缩的产品时，一定要严格把控其最大值，以防止过分的扩展。另外在成本管理中心也可以设定某些资源、某些账户的成本最大值，这样也能防止某些部门成本超标问题。
• 了解云上产品成本计费方式：一定要了解云上各个产品的计费方式，这是你作为成本控制和预算的基础。同时也是你成本优化的条件之一，不同解决方案可以符合需求，但是不同解决方案却又不同的成本。
• 成本优化：就如上面所说的不同解决方案可以符合需求，但是不同解决方案却又不同的成本。成本优化其实在云上架构是一个重中之重，也是你想到达到上云降低成本的必须条件。
• 善于利用云上成本工具：云厂商在成本管理上面都会有很多管理工具，这些都是你需要去了解并使用的，比如折扣券、优化建议、成本管理中心、预警等等，你需要擅长利用这些工具，这样才能将你的云上架构成本降到最低。

3 云架构的一些思考

上面通过2.1-2.10的10个步骤讲述一个云架构设计过程，当然并不能代表全部，毕竟云的发展很快，可能在某些案例中有更为特别的设计原则，但是大体上符合大部分上云的解决方案吧。从长远来看，云计算对我们的影响只会越来越大，下面是我对云架构的一些思考

• 改变思维模式：这是最难一部分，你先要改变思维模式。比如你面对的是服务而非资源、你需要利用云特点而不是部署云、你在考虑安全需要多方负责而非你自己负责等等。改变自身的思维模式是上云最开始也是最重要的一步。
• 建设云文化：文化这种东西说起来有点虚无缥缈，但是我觉得如同企业文化一样，看起来虚无，但是其实一直会影响人的思考和选择。因此云文化的建设也是你在上云非常重要的一部分。
• 新的商业模式：技术的变化往往会带来商业模式的变化，这就是云计算带给我们新的不一样。因此有时候上云也是要多多思考自身的商业模式是否也能匹配上云，或者说利用云技术提升核心竞争力。