导读问题：

1、SaaS,PaaS,IaaS分别指什么？

2、作为一个leader如何进行合适的云计算服务模式设计？

3、传统和云计算服务的优势和劣势？如果是你来负责技术团队，应该如何决策？

一、技术leader的抉择

一个猎头挖你到一家公司作为技术leader，或者你是初创团队的CTO/技术总监。可能会面临的如下问题：

• 1、是有着众多赛道的选手产品作为竟品，你如何能够快速的支撑业务变化需求和专注于你的产品设计和业务？
• 2、你的公司没有那么多资金投入，挖不到很多专业人才，只能给你配备外包团队人员临时支持。
• 3、你的公司没有那么多支持，需要你一个人想办法在资金和人力有限的情况下，先run起来项目。

这个时候的你可能会可能如下图片：你会怀念原来的团队，和原来的公司基础设施，以及自己游刃有余的工作场景，但是面对现在高额的薪酬，却无法解决问题的能力而焦头烂额。

自研

1、业务方案：调研现在业界的流行框架，适配业务的方案，可能会遇到的困难点，以及根据业务需求，画出原型，画出领域模型，进行数据建模，进行系统概要设计，详细设计，不断勾勒和交流业务领域专家，达到目标一致。

2、人力安排：另外一方面可能招聘相关技术人员，产品人员，设计人员，测试人员，运维人员，运营人员等来协助。

3、硬件支持： 其他方面可能购买服务器等硬件资源。

一切就绪，跟着原型和系统详细设计进行开发，并交付给领导或者最终用户。

外采

比如阿里的第一版淘宝一个月完成了上线，很多其他公司产品也是，对于一个核心技术不能掌握，以及自己的业务模式不知道是否正确的情况下，最快的方式便是兼并或者收购，或者外采。

托管

说起托管，大家都了解的github代码托管仓库。其实云服务也是一种托管，比如阿里云，腾讯云，亚马逊云等。我们可以通过按需付费，不花冤枉钱，直接通过阿里云购买服务器，域名解析器，负载均衡器，数据库，以及享受专业团队的技术支持和解决方案的共享。另外对于团队，只需要关注自己的业务应用系统如何设计更好的满足用户需求就可以了。

所以这里我们能够看到的是如果说在团队初期，我们开始搭建团队并开始项目旅程的时候，应该是外采-》托管-》自研的这个过程会比较合适。那么我们接下来重点说明下云服务下的托管决策。

二、云服务的选择

云服务模式

SaaS全称为Software-as-a-service， 软件解决方案（Saas），意思是“软件即服务”。 在业内，SaaS被 称为软件运营或简称软营。 SaaS是一种基于互联网提供软件服务的应用模式。

PaaS 全称是 Platform as a Service ，中文含义是 平台即服务

IaaS 全称是 Infrastructure as a Service ，中文含义是 基础设施即服务

也许对于上面你可能会有一种疑问，似懂非懂的感觉。我们可以看下如下的一张图：

基础设施，比如数据中心，磁盘存储，网络，服务器，防火墙，负载均衡等等就是阿里云，亚马逊云服务厂商提供出的IAAS服务产品。

操作系统，编程语言SDK，应用服务器，中间件MQ,Redis，数据库MySQL等，则是这些服务厂商提供出的PAAS服务产品。

认证，登陆授权，用户界面，控制面板，管理，事务控制则是这些服务厂商提供出的SAAS服务产品。

现在的你是否有一丝了解了呢？

这里的云计算服务的特征必须满足如下要求：

• 网络接入
• 弹性
• 资源池化
• 可计量服务
• 按需自服务

总的一句话概括就是，按需付费，我的业务发展好，数据量上来了你可以给我弹性扩容，我的业务不好，你可以给我弹性缩容，计费方式根据我使用情况来计算。比如新浪微博的热点一旦挂掉，就需要赶紧和阿里云申请扩容。之前的钉钉由于疫情在线直播的数据量导致的系统不稳定，无法扛住流量，也是紧急和阿里云申请机器扩容。

云服务的部署模式

公有云，一种多租户环境，最终用户与其他消费者一起，在一个共享的商业资源网络上为自己所使用的资源付费。

好处：

• 公用事业价格：最终用户只为所消费的资源付费。
• 弹性：弹性扩容
• 核心竞争力：管理基础设施的专业团队

缺点：

• 控制：最终用户依靠公有云提供商履行他们在性能和正常运行时间方面的服务等级协议SLA。
• 监管问题：国家专门的机构进行监管
• 有限的配置：通用的配置并未私人特制化

那么既然根据好处和缺点，我们便能够决策出，涉及到的隐私数据，我们应该部署到私有云，而普通的数据可以部署公有云。

三、我们是否需要云架构解决方案

业务架构要解决什么

对接触点和业务功能要有很深的了解，可以画一张业务架构示意图来开始，来尝试问如下的问题：

• 业务领域专家背后的逻辑是什么？
• 用户真正的需求、痛点是什么？
• 要试着解决什么问题？商业驱动力是什么？价值是什么？
• 我们的用户是人还是系统？
• 功能性需求和非功能性需求是什么？
• 云服务消费地和数据的存储地有关的法律是否允许？
• 云服务能通过哪些设备和接触点进行访问？现在的用户通过多种渠道消费数据是否能够支持？
• 我们最终的可量化的目标基准值是什么？

这里的每一项内容都决定了，是否你的云服务模式适合你当前的场景，你的上云之路是否是正确道路。

除了上述内容之外，你还需要对当前现状有个充分了解，例如如下的因素也应该是你作为技术leader应该考虑的方向：

• 1、对于云服务是否是过于自满而忽略了一些落地场景
• 2、未能创建有力的指导联盟，导致其他人员不认可和不配合
• 3、低估愿景的重要性，只考虑当下，未来的内容不考虑
• 4、未对愿景进行充分沟通，大家没有拉齐认知
• 5、放任障碍阻挠变革，为之后留下祸根
• 6、未能产生快速成果，效果可能并不明显
• 7、过早宣布成功，乐观的忽略了云服务的劣势带来的影响
• 8、变革未能扎根企业文化，企业文化未能正确普及，导致后期变革乏力

如果上述我们的顾虑都已经考虑完毕，并且已经通晒全员达成相同认知，那么就要选择合适的云服务模式了。

抉择合适的云服务模式

云服务模式的可行性考虑因素：

• 技术：性能，扩展性，安全性，监管，业务可持续性，灾难恢复等
• 财务：对于预算和采购等预估
• 战略：方案加速上市，决策者选用Saas或者Paas而非Iaas的可能性越大
• 组织：根据团队技术能力来判断选择何种模式
• 风险：公司承担多大风险，方案多久能交工运行，安全漏洞会造成多大的损害

何时选择SAAS服务

最常见的是CRM、ERP、审计、人力资源和工资单等企业业务应用，这些软件已经有成熟的业界解决方案，我们并不需要再自己研究一套。另外对于如下的服务应用也可以考虑：

• IT基础设施类：安全，监控，日志记录，测试等
• 数据类：商业智能，数据库即服务，数据可视化，仪表盘，数据挖掘等
• 效率工具类：协作工具，开发工具，调研。

何时选择PAAS服务

数据库，中间件，操作系统等要求的如下因素多语言支持SDK，安全补丁，日志，监控，弹性扩展，故障转移，灾难恢复等，都应该由供应商负责，我们可以直接选择云厂商的产品。

何时选择IAAS服务

如果对于要求开发管理内存，配置数据库，应用服务器，最大化吞吐量，明确数据如何在磁盘之前分布和操作系统有个自己的把控能力的团队可以不考虑了，如果说对于这些没有人力和能力来把控，则可以交给服务厂商。

四、上云服务的关心因素

审计

审计的核心是保护公司和客户的数据安全，这里会经常有人说云中的数据不安全。数据在哪里都会面临网络威胁，我们不应该关注云中数据安全不安全问题，应该专注哪些有关审计，法律合规，客户需求以及风险等真正的问题和约束。

在我们项目开发初期就应该考虑审计需求比如消费者的成熟度。另外对有关安全，日志，监控，SLA管理，灾难恢复和其他合规云服务的关键组件进行策略设计。

数据

数据首先需要区分是否是隐私需要保护的数据，如果是的话，我们需要利用开源的OpenStack来搭建自己的私有云，而对于非需要保护的数据，我们可以直接使用公有云来提供服务。

在对云服务进行选择的时候，数据因素的考察也决定了你选择哪个厂商，具体的因素可以参考如下几点：

• 物理特性：数据的容量、数据是否敏感、数据增量/全量、数据所有权
• 性能要求：实时、近实时、延时
• 使用缓存层
• 减少数据集大小
• 将数据库区分为只读节点和只写节点
• 将数据进行切片，分成特定客户切片，特定时间切片，特定区域切片
• 对陈旧数据归档，降低表的大小
• 对数据集非规范化处理
• 易变性：数据变化的频率，静态数据集和动态数据集
• 静态数据集：事件驱动的数据，按时间顺序发生。比如Web日志，事务和收集数据。一次写入和多次读取
• 动态数据集：RDMS关系型数据库解决通过ACID事务
• 容量：容量预估和备份策略
• 监管要求：加密
• 事务边界：性能边界
• 保存期限：数据必须保存的期限

除上述因素外，还需要考虑所有的数据需求都会对如何存储底层数据造成决策影响，比如数据是否需要隔离，以及数据存储格式：

• 多租户还是单租户
• 使用何种数据存储格式：SQL、NoSQL、文件等。

多租户还是单租户

多租户分为完全隔离和数据隔离。

完全隔离：

优点：提供独立性，隐私，高扩展性

缺点：费用最高，复用性最低，最复杂。

数据隔离：

优点：成本效率最高，复杂度最低，复用性最高

缺点：缺乏独立性，性能最低，扩展性最差

如何选择，根据流量的大小来抉择，如果流量大则完全隔离，如果流量小则数据隔离。

选择数据存储类型

联机事物处理OLTP行为。

• 键值存储：Redis，Voldemort，DynamoDB：海量数据写入
• 列存储：Hadoop和Cassandra：允许出现空缺行值，扩展性好，不适合高度连接数据源
• 文档存储：MongoDB,CouchDB：处理不同格式的文档，比如数据库日志，Web服务器日志，应用服务器日志等
• 图像数据库：比如Neo4j和InfoGrid：绘图方面有优势，其他一般
• 其他存储：比如内容分发CDN是流媒体和其他带宽密集数据的选择工具

安全

安全程度的评测

• 目标的行业
• 客户期望
• 所存储数据的敏感性
• 风险承受能力
• 产品成熟度
• 传输边界：数据发出和接收的端点如何定义

需要根据自己的用户人群以及自己的数据和产品成熟度，公司业务和风险承受能力来进行综合衡量。

PAAS的不同模式部署

• 公有托管模式
• 公有代管部署模式
• 公有非代管部署模式
• 私有托管模式
• 私有代管部署模式
• 私有非代管部署模式

安全应该关注的方向

• 集中化：根据角色划分，货仓入口，购物入口，车辆入口来集中化的管理入口保证安全
• 标准化：例如采用公认的OAuth和OpenID
• 自动化：可以参考《凤凰实验》书描述的案例

焦点领域的关注

• 保护：安全控制，策略和流程
• 检测：挖掘日志，触发事件和主动找出系统内安全漏洞的过程
• 预防：用什么行动来防止进一步的损害，你的入侵预防措施在哪里？

安全控制的策略问题

• 策略实施：规则与应用解藕，可配置能力，自动化
• 加密：静态存放指的数据存储的位置，通常数据存储在数据库中，有时候以文件的形式存放文件系统中。IP地址，服务器名称，密码，密钥。可以将所有需要加密的数据统一管理。设计时候考虑简洁和性能，加解密耗费性能影响。
• 密钥管理：公私密钥对，公钥保护的任何对象，只能私钥解密。不以明文存储，不再代码直接引用，密钥应用集中管理。密钥应该放在被隔离和保护的环境里，访问受限，有备份和恢复措施，并且完全可审计。
• 网页安全：注入SQL，劫持用户会话。对于系统定期扫描提高应用的安全等级
• API管理：API支持OAuth和OpenID，如果存在不能使用上述的场景，那么使用通过SSL进行的基本认证。避免会话和会话状态来避免会话劫持的发生。另外一种方案：处理每一个请求时候重置认证。
• 补丁管理：自动化方式进行，至少每30天创建并生成一个包含所有最新和最重要的安全补丁，实现部署过程的自动化
• 日志：所有系统记录的采集。
• 监控：系统健康程度和活动发生的信息，实时活动和挖掘日志文件
• 审计：核查安全流程和控制来确保系统符合所要求的法规控制以及满足系统安全要求与SLA过程。

监控

明确自己关注的监控点

比如我们通常关心的 RT响应时间，运行时间。页面加载时间，网络性能，应用程序接口性能等。线程，缓存，内存和CPU利用率，每秒请求数RPS，磁盘空间容量，以及CPU和内存利用率，访问数量PV，UV，新用户数，单用户成本，以及其他业务相关指标。

应该监控的类别：

• 性能
• 吞吐率
• 质量
• 关键性能指标KPI
• 安全
• 合规

监控在云堆栈的不同层进行：

• 用户层
• 应用层
• 应用堆栈层
• 基础设施层

不同的领域监控

• 云供应商环境
• 云应用环境
• 用户体验

SLA

定义参考的因素来源于不同的服务，不同的客户人群，不同的业务。

不同的服务，客户，业务对于SLA类型也不同常用的如下：

• 应用/服务的整体运行时间
• 页面加载时间
• 事务处理时间
• API响应时间
• 报告响应时间
• 事件解决事件
• 事件通报事件

消费方和企业云服务厂商的要求：

• 安全和隐私保障
• 公开的突发事件响应计划
• 网页漏洞扫描和报告
• 已发布的灾难恢复计划
• 安全港协议
• 数据所有权声明
• 备份和恢复处理文档
• 源代码托管

对于供应商的直接SLA服务要求：正常的运行时间SLA介乎99.9%～100%

灾难恢复

明确什么是故障时间成本

• 恢复时间目标RTO或者业务要求服务恢复运行所需要的时间
• 恢复点目标RPO或者数据损失在可忍受范围内的时间数
• 价值，灾难恢复的价值，比如银行数据系统资金系统等
• 服务的关键程度，比如医院医疗设备等

我们根据故障时间成本来制定不同的云服务的恢复计划。

IaaS的灾难恢复如何规划

举个例子：亚马逊分为地区和可用区域概念：地区坐落全球范围，区域是地区之内的独立的虚拟数据中心。

为了不避免系统失效，通常会跨区域冗余部署。跨地区冗余部署，或者混合云部署。

所以为了避免系统故障而可以采用这两种方式来进行处理。

主要数据中心的灾难恢复

从数据中心防备主数据中心发生灾难的恢复方法：

• 经典的备份和恢复方法：每日进行完整备份和增量备份，为了特别的安全还可以备份
• 冗余数据中心-单活冷备：冷备平时并不运行和启动，出现紧急问题根据脚本进行执行。
• 冗余数据中心-单活温备：热备意味着数据库服务器时刻运行并始终与主数据中心保持同步。而其他服务器依然冷备，这样可以减缓灾难恢复时间。
• 冗余数据中心-双活热备：双活都在运行，一个数据中心发生故障不会造成任何的影响。

PaaS的灾难恢复策略

最好的方式是公有云和私有云都有部署，方便自己把控私有云，出了问题以后不需要一直等待其他人的修复。

SaaS的灾难恢复策略

数据进行定时归档，并定期计划性的抽取数据

混合云的灾难恢复策略

• 混合IaaS（专有）：专有的公有云提供商
• 混合IaaS（开源）：OpenStack的使用
• 混合PaaS：私有PaaS实现公有和私有云之间的故障转移

五、上云服务的未来

当应用全部部署云服务以后，后续团队就需要更加关注业务需求和设计以及用户体验，从而给用户带来更好的价值和使用感受。那么未来的演化方式就会变成逐步的PAAS平台即服务，提供不同的服务平台化的能力来帮助你更好的专注的关心自己的产品或者系统。

小结

5W1H的重要性，应该在云服务模式抉择中深度思考,进而能够更好的抉择云服务设计架构。

• 原因(Why)：我们在试着解决什么问题？业务目标和驱动力是什么？
• 何人(Who)：谁需要这些问题得以解决？内部/外部参与者都有谁？
• 什么(What)：业务和技术需求都是什么？有哪些法律和法规的约束，风险是什么？
• 何地(Where)：将在哪里提供服务，有没有特定的需求，法律，税收，可用性问题，语言等
• 何时(When)：服务需要什么时间提供，预算是多少，与其他方案有没有关联。
• 如何(How)：组织如何交付这些服务？组织、体系架构和客户是否都做好了准备？