三、云计算篇

本系列教程是学院君在极客时间学习赵成的运维体系管理课记录的学习笔记，希望对有这方面需求的同学有所启发，如果想要深入了解细节可以去极客时间订阅该专栏。作者介绍：赵成，美丽联合集团技术服务经理。

为什么要选择上云

IDC 托管 -> 混合云

• 成本闲置：为了应付大促采购机器，平时低负载
• 基础设施维护：机房选址、机房扩展、资源利用率
• 底层技术投入和人才：业务导向公司不会对底层技术进行无限度投入

混合云

“混合云”即私有云和公有云的混合搭配

完全托管 IDC 模式 -> 资源短期租赁模式 -> 同城混合云模式（运营商的公有云）-> 公有云体系内混合云模式（独立物理资源）-> 公有云

以上针对云计算出现之前已有自己托管IDC的公司上云过程，新业务新公司可以完全基于公有云搭建技术体系。

Spring Cloud

Spring Boot 可以支持快速开发单个微服务应用，Spring Cloud 则提供一系列的服务治理框架，比如服务注册、服务发现、动态路由、负载均衡以及熔断等等能力，可以将一个个独立的微服务作为一个整体，进行很好的管理和维护。

Spring Cloud + AWS = PCF（Pivotal Cloud Foundry）：

Spring Cloud 除了提供微服务治理能力之外，还成为了微服务应用与云平台上各项基础设施和基础服务之间的纽带，并在其中起到了承上启下的关键作用。

Spring Cloud 不仅仅是微服务治理解决方案，它同时还是面向应用层的云架构解决方案。

注：Dubbo 也是服务治理框架，但是由于开源维护不力，现在的主流是 Spring Cloud，此外 Spring Cloud 提供的云架构解决方案也是之前 Dubbo 不具备的。

CNCF（Cloud Native Computing Foundation）：

跟业务无直接关系且相对通用的技术在不断地被标准化，而且标准化层面越来越高。从最底层的硬件和网络设备，到上层数据库、缓存、文件存储以及消息队列等等基础组件服务，再到 Spring Cloud 和 Service Mesh 这样的应用层面的服务管理和治理能力，都正变得越来越标准和通用。

CDN和云存储

自己存储 -> CDN + 云存储 -> 公有云

上云优势：

• 技术方面：专业人做专业事、业务导向
• 成本方面：商务角度议价成本优惠力度、CDN带宽费用、CDN回源带宽费用、存储空间费用
• 生态优势，强者越强

页面静态化架构和二级CDN建设

我们通常意义上讲的 CDN，更多的是针对静态资源类的内容分发网络，最典型的就是电商的各类图片，还有 JS 和 CSS 这样的样式文件，通过 CDN 能够让用户就近访问，提升用户体验。这类文件只是以单纯的资源存在，与业务逻辑没有强关联，所以我们在技术上，可以使用业界通用的 CDN 和云存储解决方案。

页面静态化架构

以商详页为例，将基本属性中基本不变的信息作为静态内容，而价格、库存、优惠活动等作为动态内容。

静态架构中，我们采用的技术方案是 ATS，也就是 Apache Traffic Server。

ATS 是一个开源产品，本质上跟 Nginx、Squid 以及 Varnish 这样的 HTTP 反向代理是一样的。但是它能对动静态分离的场景提供很好的支持。

关键技术点：

• 动静态分离：将页面上相对固定的静态信息和随时在变化的动态信息区分出来，静态信息直接在 ATS 集群获取，动态信息则回源到应用层。通过 HTTP 请求调用获取，最终通过 ATS 组装后返回给调用方，从而实现了动静态资源的分离。
• 动态数据获取：直接采用 ATS 的 ESI 标签模式，用来标记那些动态的被请求的数据。
• 失效机制：分为主动失效、被动失效和定时失效。对于静态信息来说，我们也允许它变化，但因为静态信息自身的特性，决定了它不会频繁变化。所以，我们会有一个失效中心，即 Purge Center。失效消息通过 HTTP 的 Purge 方法发送给 ATS，而失效中心则会通过订阅消息系统中特定的 Topic，或者 MySql 中特定的 binlong 变更，执行失效。

页面静态化与公有云相结合的方案：二级 CDN 建设。

二级 CDN 建设

• 回源线路，公网回源（IDC托管）转变为专线回源（云）
• 弹性伸缩（上云之后大促期间动态扩容）
• 高可用保障（CDN节点挂掉通过 HttpDNS 切换 IP 回中心节点）、

弹性伸缩

• 服务器的弹性伸缩。针对这个场景，假设业务是运行在私有云或公有云上，那我们只要能够通过云平台的 API 申请和释放资源，申请时初始化我们的操作系统，释放时销毁资源就可以。不过，在私有云环境下，为了能够保障弹性，我们必须自己提前采购、上架、装机、配置然后交付资源，需要大量的准备工作，公有云上就可以省去这些步骤，可以即拿即用。
• 应用的弹性伸缩。这个场景下其实是默认包含第一步的，就是我们首先必须要拿到应用运行的服务器资源才可以，这一步做到了，下面就是应用的部署、启动以及服务上线接入流量。
• 业务的弹性伸缩。我们可以再进一步思考，通常一个业务可能会包括多个应用，所以为了保障整个业务容量充足，这个时候扩容单个的应用是没有意义的，所以这时要做的就是扩容多个应用，但是这里面就会有一个顺序问题，先扩哪个，后扩哪个，哪些又是可以同时扩容而不会影响业务正常运行的，再进一步，业务承载的服务能力提升了，那网络带宽、缓存、DB 等等这些基础设施需不需要也同时扩容呢？

本系列教程导航索引：

• 赵成的运维体系管理课学习笔记系列（一） —— 基础设施篇
• 赵成的运维体系管理课学习笔记系列（二） —— 持续交付篇
• 赵成的运维体系管理课学习笔记系列（三） —— 云计算篇
• 赵成的运维体系管理课学习笔记系列（四） —— 稳定性实践篇
• 赵成的运维体系管理课学习笔记系列（五） —— 故障管理篇