【学习目标】

1.知识目标

熟悉微服务的概念、优缺点。

掌握微服务的整体架构。

熟悉ZooKeeper的基本运转流程。

掌握服务发现的概念、工作模式。

熟悉服务自愈的概念。

掌握架构设计优化的一般流程、策略。

熟悉云服务压测的概念、工作原理。

掌握云服务容量管理的概念、工作流程。

2.技能目标

能够根据提供的案例进行云服务架构的优化。

【认证考点】

微服务的概念、优缺点、微服务的整体架构。

ZooKeeper的概念、基本运转流程。

服务发现的概念、工作模式。

服务自愈的概念。

架构设计优化的一般流程、策略。

云服务压测的概念、工作原理。

云服务容量管理的概念、工作流程。

项目引导：云服务架构设计与优化

【项目描述】

小王所在的公司是一家传统的零售企业，在互联网+的冲击下，开始转型电商。小王的领导决定把电商系统部署在腾讯云平台上，要求小王设计在云上部署电商系统的方案。小王根据多年的经验，将应用服务器和MySQL数据库服务器设计为高可用架构。因为第一次上云，领导也没有提意见，按照小王设计的架构在云上顺利部署。然而在电商业务运转一段时间后，系统碰到大量的问题，影响了电商系统的使用，这时小王通过咨询腾讯云架构师，对部署的系统进行了重新优化，保证电商系统可以正常高效的使用。

知识储备

8.1 微服务

8.1.1 微服务简介

微服务（或微服务架构）是一种云原生架构的方法，其中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成。这些服务通常①有自己的堆栈，包括数据库和数据模型；②通过表现层状态转化编程接口（REST API）调用，实现事件流和消息代理的组合相互通信；③是按业务能力组织的，分隔服务的线通常称为有界上下文。

有关微服务的许多讨论都围绕体系结构定义和特征展开，下面来看下微服务的特点：

（1）可以更轻松地更新代码；

（2）团队可以为不同的组件使用不同的堆栈；

（3）组件可以彼此独立地进行缩放，从而减少了因必须缩放整个应用程序而产生的浪费和成本，因为单个功能可能面临过多的负载。

在微服务出现之前，软件或云平台的架构多数是单块应用架构。在软件或云平台开发中，经常会有一个或者少数几个“巨无霸”进程，里面可能包含了“用户管理”、“订单管理”、“支付确认”、“物流”等各种复杂的业务逻辑和功能，传统的单块应用架构风格是很直观、自然的，然而互联网开发领域中，单块架构遇到了一些问题。

（1）耦合严重，单块服务内的各个逻辑之间，往往缺乏清晰的边界，导致内部耦合严重，正所谓“牵一发而动全身”。

（2）维护困难，单快服务包含了过多的业务，代码量严重膨胀，开发人员不知道如何下手。

（3）团队协作困难，如果多人同时开发同一个单块应用，势必导致代码冲突成为常态，团队协作成本急剧上升。

（4）测试困难，单块服务是作为一个整体进行开发、上线的。可能开发人员只对Ａ功能进行了修改，但难免会影响Ｂ功能。随着单块应用的愈发膨胀，测试工作量会提升数倍。

上述单块应用的缺点，在传统软件开发中，尚可通过“小心规划”、“人海战术”等方法解决。但到了互联网时代，就很难实现了，为什么这么讲呢？互联网软件开发，讲究的是“快糙猛”，对迭代速度的要求非常高。对于成熟的互联网企业，一个项目在一天内上线好几次，都是稀松平常的事情。试想一下单块巨无霸服务，稍微改动一点，就要经过复杂的代码评审、测试验证，如何才能跟上快节奏的迭代和上线呢？

微服务的出现，从一定程度上改善了这种情况，微服务将单块应用划分成一组小的服务，服务之间相互协作，以组合的形式，实现复杂的业务功能，微服务的优点有：

（1）低耦合，在单块服务中，不同业务的逻辑耦合在一起。做微服务拆分后，微服务内只包含有限的业务逻辑，耦合也随之大大降低；

（2）易维护，微服务内部只包含单一业务逻辑，功能更为集中，更便于开发人员聚焦问题和修改；

（3）适合团队协作，拆分为微服务后，每个服务中涉及的代码和功能更少，可以将不同微服务划分给不同团队甚至个人负责。各司其职后，有效降低了开发和代码冲突，使得其适合团队协作；

（4）测试成本低，在单块服务中，哪怕只改动了一点点代码，也需要对整个巨无霸服务进行测试。微服务拆分后，功能的修改，只需要涉及改动的个别微服务进行测试，有效降低了测试工作量；

（5）易横向拓展，在单块服务时代，巨无霸服务已经占用了大量资源，机器的配置已经很高，若要再单独部署一个结点做负载均衡，成本会非常高，所以多数情况下，都是通过纵向拓展的方式提升系统性能（如加内存，换个更好的CPU）。采用微服务拆分后，各个微服务占用的资源更少，可以轻松的通过增加节点的横向拓展方式，提升系统性能。更进一步的说，根据阿姆达尔定律，微服务拆分后，各个微服务对性能的要求并不一致，可以优先拓展那些具有性能短板的微服务，有效降低了拓展成本；

（6）加快迭代速度：微服务低耦合、易维护、适合团队协作、测试起来成本更低，也更易于横向拓展。采用微服务架构后，可以显著的提升迭代速度。

尽管微服务具有这些优点，解决了单一服务的软件复杂度，提升了迭代速度，但也带来了一些缺点，微服务架构的缺点有：

（1）运维难度加大，在单块架构中，不管改动多少需求，只需要上线一个服务。而采用微服务后，为了一个需求，可能要上线一堆服务；

（2）开发能力要求高，在单块架构中，巨无霸服务的逻辑都在一个项目中。采用微服务后，逻辑分散在不同的项目中，在加上微服务架构本身引入的新技术，对开发能力提出了更高挑战；

（3）调试难度更大，在单块架构中，软件开发人员只需要关注一个或少数几个服务。应用微服务架构后，后端系统演变为分布式系统，可能会出现Ａ调用B，Ｂ调用Ｃ，甚至Ｃ还要调用Ｄ的长调用链，势必增加了调试和问题排查的难度。

幸运的是，通过容器等的新技术的引入，以及合理的架构设计，这些缺点都可以得到一定程度的缓解。

8.1.2 微服务架构

下面来学习微服务的整体架构，微服务的整体架构如图8-1-1所示。

如图8-1-1所示，微服务架构可以分为五个层次，下面自底向上，逐层做下解释。

1.础设施层

微服务是后端服务，最终一定要部署在基础设施的某台机器上，基础设施层可以是自运维的服务器或机架，也可以选用云计算的虚拟机。在这一层，用户重点关注底层物理资源的可用性及调整，底层物理资源包括计算资源（如CPU、GPU等）、存储资源（如内存、硬盘等）、网络资源（如交换机、路由器等）。对这些基础设施的维护，或者直接在机房维护，或者操作云平台的API进行维护。

举几个例子来进行说明，大促前预估系统容量不足，企业要加半个机架的机器；直播平台今晚要进行线上直播，预计带宽不足，要增加带宽。这些都是在基础设施层要关注的内容。

2.运维平台层

对于后端服务的运维工作，持续交付是最重要的能力。由于微服务数量众多，一般需要构建一个持续交付系统，来完成微服务的自动运维，如微服务的初始化、发布、回滚、扩容。

采用微服务架构后，上线的次数、频率都会显著提升，这就需要一个上线的镜像版本管理系统，记录上线的镜像版本。在微服务架构中，一般采用容器技术来实现微服务的自动运维。容器是轻量级资源，隔离能力相对较弱，所以需要对容器资源进行监控，调度和管理。举个例子来说明，公司有三台物理机，现在物理机Ａ和C各运行了20个容器，物理机Ｂ运行了22个容器，假设每个容器的资源占用完全一致，那么资源调度系统会自动地将B的两个的容器调整到物理机Ａ和Ｃ上。

3.微服务设施层

假设服务A需要调用服务B，那么服务A如何获取服务B的地址（例如IP和端口）呢？在传统的单块架构中，服务数量很少，尚可采用配置静态IP、静态端口绑定的方法来解决这个问题。但在微服务时代，面对动辄成百上千的微服务，这种做法将不再可行。因此，如何自动注册、发现微服务的多个实例，是架构必须解决的核心问题。

微服务拆分后，我们的系统从单机演化为分布式系统，为了防止分布式系统的雪崩效应，微服务设施需要有熔断和限流的能力。面对众多的微服务，逐一修改配置的方式显得更加笨拙，我们需要有一个中央配置平台，快速完成微服务的配置修改。

微服务的分布式架构，会加大调试难度，所以日志的收集和预警显得更加重要，同时，用户可以根据业务日志来进行一些监控预警，这和平台层的容器监控预警是不一样的。微服务需要集成一些后端组件，如数据库、消息队列、缓存等。

4.业务服务层

在提供了微服务的基础设施后，软件开发人员可以开发各个微服务。业务服务层是一些基础微服务或业务微服务，服务之间的耦合应当做到最低。

5.接入网关层

微服务面向的用户，一般是Web、移动端、PC端等。出于用户体验的考量，服务端提供给客户端的的接口应当尽量实现结果聚合，减少请求次数。因此，一般要设置一层接入网关，负责调用业务微服务，完成结果聚合后，一并返回给客户端。

8.1.3 ZooKeeper介绍

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google Chubby开源的实现，是Hadoop和Hbase的重要组件。ZooKeeper是一个为分布式应用提供一致性服务的软件，提供的功能包括有配置维护、域名服务、分布式同步、组服务等。Chubby是一个面向松耦合分布式系统的锁服务，通常用于为一个由大量小型计算机构成的松耦合分布式系统提供高可用的锁服务，一个分布式锁服务的目的是允许客户端进程同步彼此的操作，并对当前所处环境的基本状态信息达成一致。

ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。

ZooKeeper包含一个简单的原语集，提供Java和C的接口。ZooKeeper代码版本中，提供了分布式独享锁、选举、队列的接口，代码在$zookeeper_home\src\recipes中。其中分布锁和队列有Java和C两个版本，选举只有Java版本。

ZooKeeper是以Fast Paxos算法为基础的，Paxos算法存在活锁的问题，即当有多个Proposer（提议者）交错提交时，有可能互相排斥导致没有一个Proposer能提交成功，而Fast Paxos做了一些优化，通过选举产生一个Leader（领导者），只有leader才能提交proposer。

ZooKeeper的基本运转流程为：

（1）选举Leader；

（2）同步数据；

（3）选举Leader过程中算法有很多，但要达到的选举标准是一致的；

（4）Leader要具有最高的执行ID，类似root权限；

（5）集群中大多数的机器得到响应并接受选出的Leader。

那么ZooKeeper能做什么事情呢，举个例子进行说明，假设用户有20个搜索引擎的服务器（每个负责总索引中的一部分的搜索任务）和一个总服务器（负责向这20个搜索引擎的服务器发出搜索请求并合并结果集），一个备用的总服务器（负责当总服务器宕机时替换总服务器），一个Web的Cgi（向总服务器发出搜索请求）。搜索引擎的服务器中的15个服务器提供搜索服务，5个服务器正在生成索引。这20个搜索引擎的服务器经常要让正在提供搜索服务的服务器停止提供服务开始生成索引，或生成索引的服务器已经把索引生成完成，可以提供搜索服务了。使用ZooKeeper可以保证总服务器自动感知有多少提供搜索引擎的服务器并向这些服务器发出搜索请求，当总服务器宕机时自动启用备用的总服务器。

8.1.4 服务发现

随着微服务的大范围应用，服务发现这个词也变的越来越火热。下面对服务发现这个概念进行介绍，介绍主要包含两部分，服务发现的定义，服务发现的模式。服务发现是什么呢？其实，我们日常的很多普通操作，都是在做服务发现，下面我们通过图8-1-2所示的例子来理解服务发现的概念。

如图8-1-2所示，这是一个在浏览器输入域名，然后获取网站服务的流程。在这个流程中，DNS服务器会根据用户的域名解析出一个IP地址，返回IP地址中对应链接包含的内容。用户根据特定的标志（域名）来获取所需要的服务，这就是服务发现。而在微服务的领域，我们将应用拆分成一个个的微服务之后，服务发现，则变成了微服务之间相互获取彼此的信息。

然而，在微服务的场景下，使用DNS服务器作为服务发现的实现者会存在以下几个问题。

（1）DNS服务器不支持动态变更，不能够随着服务的状态变更（上线、下线、故障）而对域名映射变更；

（2）DNS只能支持域名和IP地址的一一映射，但在微服务的场景中，很多微服务都会部署多个实例，这也就要求标志与服务要有一对多的映射；

（3）DNS服务无法解决多数据中心的问题。

总的来说，服务发现就是程序如何通过一个标志来获取服务列表，并且这个服务列表是能够随着服务的状态而动态变更的。

目前，服务发现主要存在有两种模式，客户端模式与服务端模式，两者的本质区别在于，客户端是否保存服务列表信息。下面用图8-1-3和图8-1-4分别来表示客户端模式与服务端模式。

在客户端模式下，如果要进行微服务调用，首先要进行的是到服务注册中心获取服务列表，然后再根据调用端本地的负载均衡策略，进行服务调用。

在服务端模式下，调用方直接向服务注册中心进行请求，服务注册中心再通过自身负载均衡策略，对微服务进行调用。这个模式下，调用方不需要在自身节点维护服务发现逻辑以及服务注册信息，这个模式相对来说比较类似DNS模式。

两种模式的优缺点比较如表8-1-1所示。

目前来说，大部分服务发现的实现都采取了客户端模式。

8.1.5 服务自愈

大家都知道，人类是有自愈系统的，自愈是一种稳定和平衡的自我恢复调节机制。下面举例来进行说明，当前普遍采用的单下一跳路由技术来进行路由选择，这时存在两个较为严重的问题：

（1）应对网络故障的速度太慢容易导致大量丢包；

（2）单纯选择最短路径容易导致在瓶颈链路发生拥塞。

那么采用多下一跳路由技术，能较好地解决这两个问题：

（1）当网络故障导致某些下一跳失效时，通过迅速切换到备份下一跳在路由协议收敛之前继续转发数据，避免网络业务中断；

（2）多下一跳路由技术支持并行传输，能有效降低网络拥塞的风险。

所以采用多下一跳路由技术就是路由自愈的一种手段，简单来说，就是像导航一样，前方预知有堵车的路段，提前感知，给用户自动切换到最佳的行驶路线。

服务自愈就是一个服务出现了问题，例如进程卡住、进程假死，那么监控程序就会发现服务出现问题，从而采取相应的措施，可能是重启进程，也可能是重新加载进程使服务重新使用的技术。

服务的故障自愈是行业领先的“故障自动化处理”解决方案，用来提升企业的服务可用性和降低故障处理的人力投入，实现故障自愈从“人工处理”到“无人值守”的变革。通过自动化处理节省人力投入，通过预定的恢复流程让恢复过程更可靠，通过并行分析达到更快的故障定位和恢复。一句话概括，实时发现告警，预诊断分析，自动恢复故障，并打通周边系统实现整个流程的闭环。

项目实施

需要完成的任务：

• 理解云服务架构优化的概念以及一般流程。
• 理解云服务压测的概念、工作原理。
• 理解云服务容量管理的概念、工作流程。
• 熟练配置内容分发网络。
• 能够根据提供的案例进行云服务架构的优化。

8.2 任务：云服务架构优化

8.2.1 云服务架构优化术语介绍

云服务架构设计是一项综合性的规划工作，要根据业务的特点、企业的要求来合理规划、分配以及使用各种企业资源。云服务架构设计主要要关注两个方面的问题。

（1）要关注业务特点。是电商企业还是政企事业单位？是互联网应用还是线上到线下（O2O）业务？

（2）要关注企业本身的诉求。原来的IT设备要不要使用？公司的组织架构是怎么样？管理要求是怎么样的？有多少的预算？

IT基础架构的设计包括硬件规划、数据规划、网络规划、容灾规划、成本规划，由于云资源可以更灵活地使用，设计云架构比自建机房方便得多。在进行上述规划时需要考虑到业务的连续性、业务的安全，如何应对业务的变化、总成本的控制。

不合理的架构设计常导致这些问题：

（1）单点故障：某个组件单节点运行，发生故障后导致整个系统或某个模块不可用；

（2）性能不佳：用户频繁反馈访问慢，用户体验不佳；

（3）业务中断：遭受攻击或系统崩溃导致业务中断；

（4）扩展性差：在面对突发访问高峰时，不能快速扩展；

（5）成本过高：采用不合适的付费模式或过高配置的产品；

（6）运维困难：过多采用自建，导致运维工作量和难度增加。

这时就需要对原来的架构设计进行优化，架构设计优化的目的是改善由不合理架构或过时架构设计导致的问题，提供最优化方案。

架构设计优化的一般流程为：

（1）从了解现状开始，确定当前的系统架构及问题现象；

（2）接下来分析系统的需求，而不是直接定位问题。通过系统需求的分析，明确系统的业务需求，也就是我们真正要解决的问题，而不是问题的表象；

（3）找到问题的关键点，定位问题所在，并根据需求提出整体设计方案；

（4）根据整体设计方案，提出优化路径，如何实现从现有架构到最佳架构；

（5）进行查缺补漏，确认没有被遗漏的关键点。

架构设计优化的周期：

（1）架构优化是一个长期的过程，不是一次性工作，需要定期执行，或在出现重大问题时进行；

（2）考虑到云产品和云服务不断推陈出新，往往新的产品能够以更高效的方式提供服务，以新产品替代旧产品也是架构优化需要考虑的要素；

（3）之前优化过的架构，要适时的跟踪，了解优化的效果、是否还存在架构问题，如果有需要，则继续优化。

架构设计优化的策略：

（1）合适策略：合适优于业界领先，根据业务的实际情况制定合适的策略；

（2）简单策略：简单优于复杂，组件越多，故障的可能性越多，关联性也越强，问题定位越困难；

（3）演化策略：演化优于一步到位，所有的系统都是不断的适应外部环境，逐步变大变强的。

8.2.2 云服务压测

云服务压测就是指的云服务的压力测试，压力测试的目的是找出超出服务峰值负载时被测系统的行为。压力测试的结果说明了当服务负载超预期增长或是当出现突然的、意料之外的峰值时，服务可能发生什么事情。传统的压力测试不断增加负载，直到被测系统在某一刻发生某些事情。压力测试可能导致响应时间急剧增加或是系统通知事件不断出现，当然，压力测试也可能导致被测系统完全失效。对云服务进行压力测试会影响使用该服务的其他客户，因此在压力测试期间，测试人员需要确保遵守该服务的使用条款。对服务供应商来说可以享受压力测试，只要没有客户连接到正在被测试的服务就行。

压力测试的一个变种是测试系统在服务供应商承诺的负载水平边缘处的行为，执行这种测试能够帮助客户得到有用的信息。达到或超过阈值时，是出现可见的通知，还是性能表现一落千丈？负载变回到低于阈值水平后，情况会恢复吗？在这种情况下，其实是在用边界值分析方法测试负载。

有各种不同的原因导致性能下降，通常的原因包括内存溢出（日志文件、内存泄漏）、文件碎片化、或者简单地因为在不断扩大的数据集中找到特定数据变得越来越困难。一段时间后，系统性能可能会下降甚至服务会完全停止。使用实际用户负载测试可能的性能下降需要过长的执行时间，因此在容量或耐久性测试中，用户会在短时间内加入尽可能多的负载，以更快地获得结果，然而，这种做法可能带来风险，可能轻易就超过了官方允许的负载。作为客户，需要考虑没有明确标明，但在“公平使用原则”中存在的边界，然后在边界当中进行测试，在这种情况下，服务供应商自行测试服务的稳定性是明智的行为。

云平台环境中的性能下降可能表明出现了内存问题，但还有很多其他的可能原因（如不断增加的负载）。支持部门经常使用内存监控工具，显示内存的即时使用情况。用户可以结合IaaS自行执行监视，因为IaaS提供了可自行安装监控工具的（虚拟）环境，提供的环境中是否安装了监控工具不是我们选择IaaS服务提供商的标准，但可以是我们选择软件的标准。对于SaaS来说，提供监控工具是服务供应商的责任。

测试弹性是性能测试的一个新方面，对弹性进行测试的目标是确定服务的性能是否满足客户的整个负载范围，以及分配的服务容量是否与服务负载相匹配。该测试方法执行负载测试，先增加负载至超出边界（扩展），然后将负载降低到边界以下（缩减），在整个测试过程中，可能需要手动操作，同时，需要指明软件包在边界位置的可能行为。

性能测试用例一般基于负载剖面（Profiles）来实现，测试负载基于各种需求状况来建模，如平均值、最大值、压力、峰值、较低值，验收标准形成了测试依据，但还不足以用于建立测试用例。性能测试用例来源于运行情况，最好根据服务的实际或预期使用情况生成用例，这样，测试会尽可能接近真实情况，测试结果也会有足够的代表性。通常，不可能对服务的所有功能进行性能测试，需要基于风险分析进行慎重的选择（系统的运行情况可以提供重要的参考）。负载剖面描述了预期的用户数，最好带有用户活跃的时间段，剖面还需要描述用户执行的操作，注意定期（批处理）行为，例如，定期的票据操作。这些定期操作在特定的时间导致额外的（峰值）负载。如果多个应用程序在相同的位置运行，这也必须加以考虑。与被测应用具有重合高峰负荷的应用程序也会对性能产生影响。

8.2.3 云服务的容量管理

几十年来，容量管理一直用于优化组织内部资源。现在，随着IT逐步转向云环境，这种方法正在被扩展，以便在同一个地方和同一时间实现所有资源（包括云计算和本地部署）的整体规划、管理和优化。

对于现代数字企业而言，容量和成本管理对于确保足够的资源和预算来支持新的、现有的和不断增长的业务服务至关重要。在云迁移过程中，在迁移到云平台之前对资源进行适当的调整有助于防止过度配置、不必要的运营费用、云蔓延、过度管理的复杂性。性能基准测试有助于确保云计算资源提供与本地资源相同或更好的性能。在云计算资源和内部部署资源中，容量管理通过帮助组织确定其在整个环境中注意到的容量级别(包括计算配置、存储、数据库和网络带宽)，以及提供这些资源的最具成本效益的方法，来通知预测和规划。

云服务容量管理的一般流程为：

（1）导入数据，数据就是力量，如果没有数据，企业就无能为力。容量管理的关键第一步是为资源导入性能、容量和配置以及业务KPI的度量标准，其中包括物理设施、虚拟设施、云计算基础设施、数据库、存储、网络、大数据和设施。

收集这些数据有多种方法，包括从实时监控工具、行业标准中提取、直接通过API调用导入数据。企业还需要确定要收集数据的频率和精细度；大多数组织通常采用每24小时收集一次的方法，而收集的数据越多，基础信息就越全面，从而通过复杂的分析提供更好的洞察力。这有助于企业做出更好的业务决策，并变得更加主动。收集性能数据只是完全成熟的容量管理生命周期的一半，企业还需要收集业务服务模型，可能从某种发现解决方案填充到配置管理数据库（CMDB）中，发现工具为组织提供其已知和未知资产的完整清单。通常，发现解决方案也可以映射应用程序，这样可以深入了解哪些应用程序正在使用哪些基础设施，以及某些相关应用程序是否需要接近以获得更好的性能。目前的最佳实践是，在构建分析、模型、报表和仪表板时，利用在配置管理数据库中标识的标记作为筛选条件。

使用标记方法是获取服务视图的另一种方法，也是云计算服务提供商鼓励使用的方法。利用良好的标记方法，组织可以创建满足各种利益相关者需求的数据自定义视图，同时需要了解内部部署和云计算资源使用情况以及成本。典型的标记包括按部门分类、数据关键性、遵从性、实例类型、集群、用户组等。标记可以在资源配置时应用，但随着时间的推移，企业可能还需要使用容量管理应用程序定义和应用其他标记。

容量管理应用程序负责将IT和业务方面结合在一起，从简单的孤立基础设施容量管理升级到更成熟的服务级别功能，从而实现高级建模技术，例如对服务需求进行建模更改。

（2）分析数据，组织既然拥有了数据，那么还需要了解资产，以了解实际情况。许多组织缺乏对其业务服务的可见性，因为他们的业务被组织成由多个监控工具管理的技术孤岛，每个监控工具都有自己的用户界面，利用在一个位置提取和组织此数据的解决方案至关重要，这将人们带到第二步，数据分析。

分析数据应该从以下几个方面进行：

①可见性，整个环境的可见性是容量管理过程的基础。企业通过可见性来分析发现数据，深入了解其拥有的资产、资产配置以及资产所在位置。

②基线，接下来，配置正常的利用率配置文件和基线（此步骤需要机器学习）。企业需要了解一段时间内的使用模式，并确定其存在的周期性行为的类型及其原因，分析的时间越长，收集的数据越多，基线和分析的准确性就越高。持续的数据收集和分析是正确分析和基线的关键，随着时间的推移，了解资源使用模式有助于组织确定确保一致性能所需的容量级别。

③峰值分析，确定周期性行为和最繁忙的时期。了解工作负载何时发生变化对于高效使用至关重要，尤其是在云平台中，组织每天、每小时、每分钟或每秒都在为资源付费。通过理解这些行为，组织可以在不浪费资源的情况下，对如何处理应用程序和资源应用程序做出更好、更明智的决策，以确保性能。

④优化，寻找优化资源使用的机会。这可能涉及使计算配置适应工作负载的变化，例如添加内存或CPU，这就需要有效地实现自动化，人工操作通常已经过时，并且无法跟上现代企业的变化步伐。

（3）预测数据，组织通过了解当前拥有的内容、资源，可以预测未来利用率、潜在的容量限制、饱和度来更加主动地管理其环境。这些知识可以帮助组织防止服务降级，并防止潜在的中断。预测还可以了解未来配置变化将如何影响当前和预计的性能，这是容量管理过程的另一个关键方面。

通过预测，组织可以预测未来配置更改对利用率水平的影响，并在影响性能之前标记预期饱和点。要主动识别存储容量饱和度，确定存储池何时可能用完容量，量化满足分配要求所需的额外容量以及验证存储系统中是否有足够的未使用磁盘来扩展现有存储池。这个过程可以避免购买不足的情况，并满足当前和未来的存储要求，从而可以防止停机。同时，精确的大小调整有助于避免过度购买和浪费存储容量。

（4）使用数据进行规划，该步骤的重点是规划新的项目、应用程序和业务服务。这通常被称为需求管理或预留感知容量管理。在此步骤中，组织需要关注两个问题：①有足够的容量来完成这些新项目吗？②这些新项目将如何影响当前运行的其他应用程序和业务服务？

容量管理数据可以输入资源预留仪表板，以提供问题的答案，其中包括：

①拥有什么资源以及如何使用资源？

②存储什么资源以及什么时候存储？

③是否拥有现有资源或正在添加新资源？

④资源可以释放多少容量？

⑤什么时候回收资源，并将其添加回可用资源池？

预留仪表板提供每个服务所需资源的清晰可见性，这样用户就知道何时需要这些资源以及是否已提交这些资源了。

（5）预测变化和回收容量，容量管理下一步是预测服务需求变化对现有系统、应用程序和业务服务的影响。这通常被称为业务服务级别的排队网络建模，或IT基础设施资源(计算和存储)的优化。在此步骤中，容量管理器模拟特定业务场景所必需的系统更改。如模拟IT基础设施变化对业务增长与计算响应时间和资源利用率约束的影响；模拟整合和虚拟化方案，以确定潜在变更将如何推迟或消除饱和度；模拟灾难恢复方案或资源淘汰导致的服务影响，作为云迁移计划的一部分。

容量管理可以预测系统资源的未来行为，例如这些和其他许多场景，以及对业务关键绩效指标（KPI）的影响，这有助于IT将业务需求与容量需求相关联，并根据需要调整资源以支持它们。如果即将发生的事件可能会改变应用程序资源需求，组织可以相应地建模，如保险公司可能需要额外的资源来支持开放注册期；在每个学年开始时，大学需要更多资源来管理学生入学事务；零售商需要资源来支持大型促销活动和产品发布以及其他销售活动。每个企业都有可显著改变所选应用程序工作负载的事件，这些应用程序通常面向客户，对业务至关重要，并使用跨多层和共享环境的资源进行交付。

容量管理者可以通过模拟服务需求变化以及为解决这些变化而进行的各种配置或容量修改的影响，确保足够的容量来应对预期的激增。通过对这些服务需求变化的影响进行建模，可以估计饱和度和容量约束，以及了解减轻约束所需的配置和/或容量修改。并确切地知道需要做什么以及何时需要这样做以支持业务。

（6）使用数据形成报告，在数据导入、可视性、分析、预测、计划和建模之后，容量管理成熟度的下一步是能够自动生成可分发给利益相关者的报表和仪表板。这些利益相关者可以包括仅负责个别技术孤岛、业务健康状况、特定应用程序以及以上所有方面的人员。定期为每个利益相关者自动生成具有不同内容的各种报告和视图非常重要。

8.2.4 云服务架构优化实例

1.不合理架构案例分析

案例描述：小王根据多年的经验，设计了如图8-2-1所示上云部署的架构，并将应用服务器和MySQL数据库服务器设计为高可用架构。因为第一次上云，领导也没有提意见，按照小王设计的架构在云上顺利部署。

企业上云架构描述如下：

（1）通过DNS实现域名解析；

（2）通过CDN实现图片、静态文件与动态页面加速；

（3）通过在云主机上部署Nginx，实现页面转发和负载均衡；

（4）在云主机上部署可弹性伸缩的业务应用，每个应用均至少部署2台；

（5）在云主机上部署图片服务器，存储图片，提供图片处理；

（6）在云主机上部署Redis/Memcache等缓存数据库；

（7）在云主机上部署MySQL，配置为主从架构，提供结构化数据服务；

（8）在云主机上部署MongoDB，提供NoSQL数据库服务；

（9）使用VPC安全隔离的云中私有网络环境。

然而在电商业务运转一段时间后，系统碰到大量的问题，如：

（1）因为图片服务器故障，导致用户无法查看商品图片；

（2）图片服务器处理能力有限，导致用户查看商品图片慢；

（3）因Nginx服务器故障，导致整个应用无法访问；

（4）做促销活动时，由于用户暴增，系统从访问延迟到最终系统崩溃；

（5）Nginx服务器被植入挖矿木马，CPU占用100%，导致网站访问非常慢；

（6）网站经常被入侵，用户被跳转到竞争对手网站；

（7）运维工作量大。

小王被这些故障和问题弄得焦头烂额，只好求助于腾讯云架构师，希望能够通过架构优化，解决这些问题。

\2. 故障定位以及架构优化建议

架构优化切忌直接对问题进行分析，首先需要做的事情，就是调研，了解了足够的信息之后，才能对问题进行准确定位，并根据分析给出较合理的架构优化建议。

一般调研从应用和基础架构两个方面来进行：

（1）应用调研：

①调研业务架构，了解该系统相关的业务类型、需求和痛点等信息，根据这些信息来确定应用运行的需求；

②调研应用及数据架构，了解应用系统的应用架构组成、技术栈、访问量、用户分布等属性；了解结构化数据、非结构化数据架构，了解数据量大小、数据增长等属性。

（2）基础架构调研：

①了解基础的计算、存储、网络、安全等属性；

②了解区域和可用区分布；

③了解运维压力和痛点。

一个架构中对应用系统运行造成影响的，通常由以上6个部分组成：客户端、网络、前端、应用、数据、安全，如图8-2-2所示。

腾讯云架构师经过前期调研以及应用系统分析，对公司前期的云架构方案出现的问题进行了分类，如图8-2-3所示。

从上图中可以看出，前期的云架构方案问题主要分为单点故障、性能不足、安全问题，下面我们详细进行介绍。

（1）单点故障，在该案例中，小王仅考虑了应用服务器（含前端和应用）和数据库服务器的高可用，而忽略了网络、非结构化数据、可用区的高可用。这与小王的知识结构和经验有关，传统数据中心的经验不能完全照搬到云上，云有其特有的产品和特性，如CLB、可用区、对象存储等。单点故障主要表现为：

①网络的单点故障，企业需要通过Nginx服务器来实现负载均衡功能，但Nginx服务器本身就是一个单点，没有办法实现负载均衡；

②非结构化数据的单点故障，图片、音视频等静态文件存储在图片服务器，同时该服务器还兼具图片处理功能，一旦图片服务器故障，会造成图片无法访问，直接影响用户使用该服务器；

③可用区的单点故障，传统数据中心受限于成本，较少考虑同城跨机房的容灾，对应到云上则是可用区。一旦可用区出现服务故障，将会导致业务中断。

（2）性能不足，主要表现为：

①未考虑应用服务器无法应对促销活动带来的访问暴增，以当前上云部署的架构，只能手动扩展，一旦访问量超出预估，则仍会出现访问延迟；

②即使已经考虑了通过CDN来加速图片访问，但图片服务器属于难以扩展的角色，一旦用户访问量暴增，图片服务器的两个功能图片访问和图片处理都会出现性能问题。

（3）安全问题，主要表现为：

整个架构中完全未考虑安全，在传统数据中心，安全产品往往是以购买设备和软件的方式来实现，成本高、周期长；而电商业务在起步阶段，基于成本考虑，小王很难在前期即考虑安全方面的投入。

针对前面定位的问题，腾讯云架构师给出了架构优化的建议，主要从消除单点故障、对系统性能进行优化、安全优化这三个方面进行考虑，下面进行详细介绍。

（1）消除单点故障，具体架构如图8-2-4所示。

具体流程如下：

①云解析根据预设规则将流量分配到不同物理地区的不同数据中心以保障各地用户访问体验；

②负载均衡自动伸缩容量，将应用程序流量智能分配到多个物理隔离的可用区中的CVM实例，最大程度的保障前端门户的可用性；

③Redis提供标准版和集群版。支持跨可用区主从热备，提供自动容灾切换、数据备份、故障迁移、实例监控、在线扩容、数据回档等全套功能；

④CDB支持主从实时热备，并提供容灾、备份、恢复、监控、迁移等数据库运维全套解决方案；

⑤MongoDB服务提供自动容灾，无需自建灾备体系及控制管理系统；

⑥腾讯云提供完整的功能与工具，帮助电商平台快速、低成本的实现跨数据中心的远程容灾；

⑦对等连接支持跨地域私有网络互联和跨地域基础网络互联，助力企业轻松实现两地三中心容灾。

（2）对系统性能进行优化，具体架构如图8-2-5所示。

具体流程如下：

①腾讯云CDN超大的带宽储备，足以应对促销活动时爆发性的用户访问请求；

②快速伸缩的负载均衡CLB可以实时调整集群规模以自适应促销流量的增长，无需人工介入；

③弹性伸缩AS动态检测当前主机集群的负载，自动根据后端负载以调节集群大小，确保服务工作正常；

④弹性缓存与数据库集群无缝衔接，确保每个用户的会话数据高速返回，保障销量正常；

⑤对象存储COS提供不限容量的存储空间，用于存储商品图片及用户日志，分离CVM主机在促销进行中的磁盘压力。与万象优图结合，提供高可用、高质量的海量图片处理服务，同时提供图片压缩、图片裁剪、图片水印等功能，满足多种业务场景下的图片需求；

⑥高速高并发的营销短信通道SMS，可以确保促销信息即时触达到企业的每一个用户。

（3）安全优化，具体架构如图8-2-6所示。

具体流程如下：

①网络安全优化：BGP高防IP，提供30线BGP独家防御，国内单用户单点可提供900G+防护能力，海外高达400G防护能力，有效抵御各类基于网络层、传输层及应用层的DDoS攻击；

②业务安全优化：腾讯云提供针对业务安全和内容安全的多重保障，包括活动防刷、验证码反欺诈、登陆保护、图片鉴黄、文本识别甚至人脸识别，让企业不再担心业务风险；

③应用安全优化：使用Web应用防火墙，通过Web入侵防护、0Day漏洞补丁修复、恶意访问惩罚、云备份防篡改等多维度防御策略全面防护网站的系统及业务安全；

④主机安全优化：腾讯云主机安全，基于腾讯安全积累的海量威胁数据，利用机器学习为用户提供黑客入侵检测和漏洞风险预警等安全防护服务，解决当前服务器面临的主要网络安全风险；

⑤内网安全优化：私有网络VPC提供专业的租户隔离，以及包括ACL和安全组在内的安全策略，保证云内的网络安全可靠；

⑥管理安全优化：使用KMS存储服务器管理密钥，严格控制后台的管理权限；

⑦APP安全优化：移动应用安全涵盖应用加固、漏洞扫描、盗版监控、真机测试、质量跟踪、安全支付等服务，配合代码签名证书提供的代码软件数字签名的认证，免除APP收到第三方破解和串改的侵害；

⑧专业服务优化：腾讯云同时向企业提供专业的安全咨询服务、渗透测试服务等安全解决方案，全面保障企业的业务安全合规。

最后，对云服务架构优化做下总结：

（1）从需求出发，整体分析，整体设计，全面优化；

（2）找到关键点，做到不遗漏；

（3）设定优化策略，架构的优化不是一蹴而就；

（4）遵循架构设计原则。

本章小结

本章主要介绍了微服务的概念、优缺点以及它的整体架构，ZooKeeper的基本运转流程，服务发现的概念、工作模式，服务自愈的概念，架构设计优化的一般流程、策略，云服务压测的概念、工作原理，云服务容量管理的概念、工作流程；能够根据提供的案例进行云服务架构的优化。全章理论和实践相结合。读者通过理论知识学习和案例实践练习，能将知识融会贯通，提升实际动手能力。

本章习题

一、单项选择题

1.下列选项中，哪些不是微服务的缺点（ ）。

A.开发能力要求高

B.运维难度大

C.不适合团队协作

D.调试难度大

2.下列选项中，哪些不属于微服务整体架构（ ）。

A.接入网关层

B.业务服务层

C.运维平台

D.传输层

3.微服务整体架构中底层物理资源不包含哪些选项（ ）。

A.存储资源

B.计算资源

C.网络资源

D.传输介质资源

4.目前，大部分服务发现采用（ ）模式。

A.客户端模式

B.服务端模式

C.主动发现模式

D.被动发现模式

5.下列哪些不属于架构优化设计的策略（ ）。

A.合适策略

B.适用策略

C.简单策略

D.演化策略

6.下列选项哪些不是云服务容量管理一般流程的是（ ）。

A.分析数据

B.导入数据

C.保护数据

D.使用数据形成报告

7.下列选项中哪些不是架构优化中的基础架构调研（ ）。

A.了解基础的计算、存储、网络、安全等属性

B.了解运维压力和痛点

C.了解应用系统的应用架构组成、技术栈、访问量、用户分布等属性

D.了解区域和可用区分布

二、多项选择题

1.下列选项中，哪些是微服务的优点（ ）。

A.低耦合

B.易维护

C.易横向拓展

D.测试成本高

2.服务发现的模式有哪些（ ）。

A.客户端模式

B.服务端模式

C.主动发现模式

D.被动发现模式

3.下列哪些属于不合理的架构设计（ ）。

A.某个组件单节点运行，发生故障后导致整个系统或某个模块不可用

B.遭受攻击或系统崩溃导致业务中断

C.在面对突发访问高峰时，不能快速扩展

D.过多采用自建，导致运维工作量和难度增加

三、问答题

1.微服务的概念？

2.ZooKeeper的基本运转流程？

3.ZooKeeper的目标？

4.服务自愈的概念？

5.云服务压测的概念？