【51CTO.com原创稿件】互联网技术一直在快速演进当中，同时移动互联网与云时代的来临，让微服务架构应运而生。
2017 年 12 月 1 日-2 日，由 51CTO 主办的 WOTD 全球软件开发技术峰会在深圳中州万豪酒店隆重举行。
本次峰会以软件开发为主题，熊普江先生在“微服务与容器技术”专场与来宾分享了"云端微服务架构的运维思考"的主题演讲。
本文围绕微服务架构的特点与发展趋势，结合微信业务在微服务架构上的探索、应用、改进与提升，阐述运维如何应对业务在微服务架构环境下的各种挑战。
如今互联网技术呈现出两方面的发展趋势：云化的趋势和微服务。两者相结合则更富挑战性，本次我将以微信为例和大家一起探讨。
本次分享分为三个方面：
- 微服务架构的演进
- 微服务架构的特点与趋势
- 微服务架构运维的解决之道
微服务架构的演进
智能手机在移动互联网中的快速普及，中国互联网中心的相关调查表明：通过手机上网的用户比例已经高达 93% 以上；而整个中国的互联网渗透比例也已超过六成。
因此，我们所处的移动互联网时代的开发呈现出如下的特征：
移动互联时代全面来临
虽然在工作时仍然离不开电脑，但是我们使用手机来连接互联网的场景更为频繁。
由于手机的运算能力有限，手机更多地被用于展示或显示内容。大量功能化的计算处理显然需要依赖于云端。所以我们实际上处于一个瘦客户端的时代。
随着我们停留在移动互联网上的时间剧增，大量的数据也随之产生，特别是相较于传统 PC 时代，增长了数十倍、乃至数百倍。
这些大量的数据同样也需要在云端进行处理，因此我们对于云服务的能力也会有一定的要求。
硬件技术发展迅速，服务器性能越来越大。如今硬件的处理能力（特别是 GPU）发展迅速，服务器的处理能力也得到了迅速提升。
这都导致了单个应用或者单个功能模块很难消耗掉整台服务器的资源。为了提高多台服务器的资源利用率，我们需要将多个服务部署到同一台机器之上。
容器技术兴起，轻量协议支持成熟应用
在软件方面，新兴的技术包括：容器、Docker 和诸如 restful 之类的轻量协议，都加快了我们的开发与部署效率。
应用的云化逐渐普及
为了将服务放到云端，我们不再需要去买各种机器，而直接在云上运用各种资源来部署我们的服务。
该领域不仅是互联网企业的热点，其他传统企业，包括一些金融和医疗企业也都在往云端寻求探索方向。
开发模式转变
传统的单体式集中开发模式为：前端 Web→管理系统→数据库→操作系统→底层服务器。
这种从上到下的“纵切”方式势必导致了对于技术人才、硬件、网络、软件、以及技术的大量需求。
这些对于初创型企业来说，会存在全能人才难招、开发复杂、迁移与扩容难度大、无法快速的响应等困难。
因此我们需要在开发和运维方面转变思路，通过“横切”将底层资源和中间平台转包给 IaaS 和 PaaS 平台，仅集中精力在前端的业务应用上。
精细化运营转变
由于越来越多的服务都要经由云端处理，以通过各种容器来实现快速部署与扩展，因此我们必需使用精细运维，来实现对于资源的充分利用。
基于上述移动互联网时代的开发特征，一种适用于快速变化需求的微服务架构应运而生，同时它也催生了 DevOps 的概念。
它是一种敏捷的开发模式架构，能够让我们迅速地实现：编写规划→编写代码→构建测试→发布上线→部署应用。
近两年，微服务这个术语渐成热门词汇，但它不是一个全新架构，更不是一个包治百病的架构。
那么，微服务架构与单体式架构相比优势体现在哪？这些优势又给开发模式、运维带来哪些挑战？
微服务架构的特点与趋势
微服务架构的特点与趋势如下：
- 一种架构风格。微服务架构实际上并非一种新的技术或能力，而只是一种架构的风格。它大约出现在 2014 年，但是微信早在 2011 年就开始使用该架构风格和思路进行开发与运维了。
- 强调服务的颗粒度、敏捷性和健壮性。微服务能够实现快速地开发、部署、和稳健地运行。
- 单一、独立。微服务专注于解决单一问题，因此非常独立。该独立性体现在完成某个功能不依赖其他的服务，即如果该服务出错，并不会影响到其他服务。
- 解耦，去中心化，组件化封装。既然相对独立，那么业务之间就是一种解耦的关系。纵观整个应用之中的各个服务，虽然重要程度有所区别，但是没有一个服务必须以微服务为中心，因此它具有去中心化的特点。
为了能在与其他的微服务打交道时使用统一的接口，微服务也会进行各种封装。
- 多个微服务组合完成相对复杂的业务系统。我们能够快速地将各个微服务组合到一起，构建出一个能够达到特定需求且相对复杂的业务系统。
- 高性能，高容错。由于每个服务都相对独立，就能够在保持系统稳定的前提下，***地追求每个微服务的性能。在分布式的结构中，单个微服务的出错（比如硬件出现问题）不会影响到其他的微服务。
另外在多个微服务并存时，同一个服务会有多个正在运行当副本，因此具有高容错性。
微服务架构解析
微服务架构解析：
- 适用于构建复杂的应用，通过运用微服务，可以将各种模块如搭积木一般组合成相对复杂的应用。
- 分布式，由于各个微服务之间都遵守相同的协议，可以实现多个微服务的分布式部署。
- 分别部署，由于每个微服务都具有单一且独立的功能，因此服务模块的数量显然是庞大的，光靠人工完全无法实现分开部署。随着微服务的数量呈几何基数增长，我们需要用一套自动化的工具来进行快速地部署。
- 服务组件，微服务一般分为两种不同的类别：一是基础模块或称公共模块。如：用户登录、推送（Push）服务模块；另一是功能性模块，如：实现发消息或发朋友圈的模块。
- 微服务的边界，虽然用的是同一种语言，但是可以进行独立地开发与测试，因此每个微服务在被发布的时候不会跟其他的微服务共享数据存储或内存空间。每个微服务都有自己的独立空间。
- API 层，如上图所示，微服务与外界有一个接口层，它们遵守共同的协议进行通信，如 RPC 或 Restful 等，大家可以自由选择各种技术。
- 微服务架构的扩展，为了应对未来可能对现有微服务的功能性增加，或是要增加其他业务场景，我们一般不在原有微服务上着手增加，而是新建另一个微服务，并独立部署。
微服务架构的优势
微服务架构有如下几个明显的优势：
- 单个微服务更易理解，方便开发与维护。相比以往，只要定义好了一个微服务，我们在开发、维护和部署时就能方便地理解其功能意图。
- 应用解耦、对应用整体应用交付而言，开发迭代更敏捷。我们可以单独对一个微服务进行升级，而不会影响其他微服务的功能。
- 技术选择更加自由，微服务不再需要限定某个统一的技术实现。每个程序员都有自己的技术偏好，有人喜欢 Java，也有人喜欢 PHP 或是 C。
- 以往大家不得不根据统一技术框架，遵循一致的开发语言。如今每个微服务都可以用不同的语言来实现。
- 微服务独立部署，应用更稳定。由于每个微服务都不影响其他的微服务，因此单独部署会给整体应用带来更好的稳定性。
- 架构扩展更容易、更快速。如右图所示，我们从三个维度进行架构设计。其中 X 轴表示可以放置多个副本；Y 轴是通过分层来扩容服务；而 Z 轴是对服务进行数据分区。
- 这说明我们的微服务能从 X、Y、Z 三个方向去扩展整体架构。
微服务架构带来的挑战
下面是谈谈引入微服务架构时会碰到的各种挑战：
- 开发模式需要相应调整，首先要从“纵切”的开发思维转变成“横切”的思维。
- 跟以往相比，微服务的数量会大幅增加。
- 数据增多导致了容器的编排、配置与资源的管理更为复杂。相对于过去只需管几台机器而言，如今如何搭配和配置各种微服务会变得更复杂。
- 业务的容量管理变得更加困难，资源利用效率难以提升。以前我们只需要监控某几台机器的使用率。
- 如今，由于容器存在多台服务器上，就需要对容器里各种服务的资源利用率和容量进行综合管理，同时对它们的提升难度也更大了。
- 监控的颗粒度增多，依赖及关联关系更加复杂。由于微服务的增多，监控的颗粒也相应有所增加。如上图右侧所示，颗粒之间的关联关系也会变得更加复杂。
- 在微服务出现故障时，我们要有快速调度的能力，因此调度需要更精细化。
微服务架构下的运维思考
下面是我在微服务架构下的一些运维思考：
- 容量管理，即：如何在细粒度的状态下，更有效地管理数量庞大的微服务。
- 容器编排与配置管理，如何合理地实现容器编排和配置管理？
- 服务监控，如何有效地监控数量庞大的微服务？
- 故障恢复与业务调度，出现故障时如何进行业务调度？
- 快速扩展，由于春节红包或直播所导致的业务爆炸式增长或触发时，如何快速扩容？
- 资源的利用效率，运维人员需要思考如何在保障业务稳定发展的同时，控制好成本不会大幅增长，资源不会出现简单堆砌。
微服务架构运维的解决之道
下面先以微信为例，讲解它使用到微服务架构的地方，接着介绍我们在微服务容量管理方面的具体工作，然后给大家分享在监控部署调度上值得参考的地方，***探讨我们在资源利用率上的精细化运营。
微信为什么要微服务云化
自 2011 年诞生以来，微信一直强调使用快速迭代、试错、纠正的敏捷开发模式，也就是我们常说的“小步快跑”方式。
在微信内部有四个“法器”，分别是：
- 大系统小做
- 让一切可扩展
- 有基础的组件
- 能够轻松地上线
大系统小做，不仅涉及到将海量系统中的模块变得更清晰，而且在物理环境中实现分开独立的部署，以便快速发现问题。
例如：一些公共服务的注册登录、LBS 的逻辑、和类似微信的摇一摇等方面，我们都将这些逻辑独立了出来。
让一切可扩展，此处强调两个方面：
- 网络协议的扩展。通过向前兼容，以应对将来可能出现的升级。
- 数据存储的扩展。传统的 MySQL 之类的结构化数据存储，对于后期频繁增加字段的扩展性并不方便。因此微信采用的是 Key-Value 的非结构化数据结构，以方便存储上的扩展。
在 2013 年到 2014 年间，微信的微服务模块数已超过了 5000 个，我们碰到过两个问题：
- 如果在一台硬件能力超强的服务器上只部署一个模块，则势必造成资源浪费。因此我们采用了混合部署，在一个服务器上部署多个服务。
- 多个服务在一台服务器上抢资源，从而影响了服务的稳定性。因此我们采用了容器隔离。
有基础的组件，把复杂的逻辑固化下来，成为基础性软件。在微信的后台会有几种不同的基础组件，大致包括：
- Svrkit，Client/Server自动代码生成框架，实现 10 分钟搭建内部服务器。
- LogicServer，逻辑容器：随时添加新逻辑。
- OssAgent，监控/统计框架：所见即所得的监控报表。
- 存储组件，屏蔽容灾/扩容等复杂问题。
微信微服务架构的应用与管理
我们对微信里的各个微服务应用场景进行了定义：
- 服务布局，就是将用户运用不同的方法与服务维度进行“切割”和布局。
- 引入各种容错机制，如：当服务访问中断时，可自动重试；当服务运能不够时，有过载保护和负载均衡；在必要时，可随时关闭服务，实现柔性可用。
- 容量管理与监控。
- 部署管理与调度。
- 精细化运营。
我们对微服务也进行了技术分层：
- 接入层，主要实现对用户的切分，以识别不同的运营商和不同的地域。
- 逻辑层，在微信中，微服务被更多地应用在逻辑层。
- 存储层，主要应对海量数据，以及独占资源的情况。
服务布局
微信采用多地自治、园区互备的架构，城市之间的数据是相对独立的。除了少数账号全球同步以外，大部分业务都以电子邮件式的服务，各自有自身的环境在流转和通信。城市间的后备则使用公网的 UDP 通道。
在城市内，使用三园区的架构，每个园区都是一套独立的系统，从接入、逻辑、存储每一层都是完全独立的，并且可以互相为对方提供备份，多园区形成整体服务规模。
在园区内，由多机组成的 set，互为容错，包含它们的网络与电力也是独立的。这样的服务布局，不仅满足微服务架构，也考虑了容灾能力。
过载保护
过载保护是一个非常核心的微服务架构特性，目的是确保核心服务可用。
它包括三个层次：
- 服务要有轻重分离。即一个服务里不能既有重的操作，又有轻的操作。
- 队列控制。我们通过监控，来了解一个请求在队列中等待的平均时间，从而决定是否要启动拒绝或是限流。例如：对超过设定阀值的流量进行限制，确保服务可用。
- 组合命令式。由于微服务的调用链以及层次的增多，后端服务也会有多种。假定后端有两个服务（A 服务与 B 服务），而前端调用需要依赖于 A、B 服务的组合结果，那么单个 A 或者单个 B 的轻微过载，就可能导致前端服务不可用。
在这种情况下，需要有一个反馈机制。如上图所示，整个系统基于反馈，把整个拒绝的信息全程传递。上图右侧是几个典型的服务，从一个 CGI 调用一个后台服务，再调用另一个后台服务，系统会在 CGI 层面把它的重要程度往下传。
回到刚才前端调用 A、B 服务的例子，使用这样一种重要程度的传递，就可以直接拒绝那些相同用户的 20% 的请求，有效地解决单个服务轻微过载的问题。
容量管理
为了在微服务架构下实行较好的容量关系，微信做到了三个前提：
- 微服务间资源进行隔离管理
- 微服务的过载有自我保护能力
- 服务的快速伸缩操作
容量管理是为了更好地进行业务支撑，因此我们构建了需要支撑的业务与其容量之间的模型关系，从而有效地评估出那些有效的微服务所对应的容量。
如上图所示，下方的灰色线表示实际业务的容量，即业务量，如：请求量、调用量、以及用户数。
红色线表示在机器扩容或升级之后的现网容量。绿色线则表示***容量，它比现网容量要高出 20%，以保证只是偶尔被触发。
当业务需求超过现有容量时，业务就可能出现不稳定或者无法提供服务的情况。而扩容则往往涉及到复杂的数学运算。
因此由于现实中资源的采购、部署与上架存在周期，不大可能完全达到该绿色曲线。
随着公有云被广泛地运用，我们基本上能够实现及时获取容量资源。当然要保证具有较好的业务支撑的话，应当具有容量的发现能力和适当的处理效率。
在实际进行容量评估的时候，可能会碰到如上图所示的“坑点”：我们可能会将容量误解为左边的线性关系。
在某些时候，使用量上升到 60% 之前还是处于线性，可一旦升至 65% 或 80% 时，就会维持那么多且再也上不去了，如右边的容量模型所示。
所以说容量评估的困难之处就在于：一个应用或一个微服务在使用资源时会受到诸如：CPU、内存、网络、以及磁盘 I/O 等多种因素的制约。
因此，我们应当去熟悉某个微服务主要消耗资源的关键点，以及它与其他资源之间的关系。
针对容量的评估，同样在微信中引入了压测。如图所示，我们有四种模拟测试的方案：
- 模拟流量到测试环境，它对现网不产生影响。这往往由测试团队来操作。
- 真实流量到测试环境，即运用 TCP 协议复制一份流量到测试环境。许多电商经常在一些大促之前，会把一些真实的流量引到测试环境之中，以检验系统到底能支撑多久。这往往由运维和开发协同执行。
- 模拟流量到现网环境，这种并不常见。
- 真实流量到真实环境，这是在微信中使用最多主要的现网压测方式。该方法虽然最真实、且对容量的评估也最准确，但也会有***的风险。它可能会引发故障，并考验我们及时发现故障点的能力。
压测具有双面性，好的一面在于：有助于我们发现过去未曾注意的底层问题；不好的一面，则是在出现问题之后，我们可能无法快速地恢复，有时甚至并非将流量撤掉那么简单。
因为一旦某个服务崩溃了，则需要花时间和精力重新启动它。因此我们在做真实压测时，会特别注意上图所列的三点。
上图展示了过载保护的机制。当有更多的流量抵达时，过剩的流量会被直接拒绝掉，显然我们也可籍此测算出其真实的流量大小。
可见过载保护，或称快速拒绝是在微服务架构下做好容量管理的重要前提。如果没有该保护，将很难评估现网容量的门限。
微服务监控
微信实现了对于微服务的立体化监控，监控的内容包括：
- 常规指标，如 CPU、内存、网卡等。
- 快速拒绝的数量级，通过该数量级，可以进一步评估受影响的用户量。
- 耗时方面的精确数据。
- 调用失败的次数、重试的次数。
这些在监控上都有一些数据来上报及展现。由于我们监控指标非常多，同时伴随着微服务的增多，其产生的报警数量也会呈爆炸式增长。因此需要有智慧化的运维，通过 AI 应用去收敛各种报警。
就监控能力而言，我们为每台机器都部署了 Agent。这些 Agent 的监控粒度比较密集，能够达到秒级监控。与此同时，它们的数据上报能力也较为迅速。
业务部署与调度
容器的编排是微服务的一个重要方面，不同于 Docker，微信采用的是自研的 svrkit 架构，它参考了 borg/yarn/k8s/mesos 等主流调度系统的特点，该容器调度的微服务覆盖率超过 80%。
微信的容器调度系统叫做 yard。如上图下方所示，它分为两层架构：
- Resource Manager 和 Node Manager，负责资源管理。
- Application Master 和 API/Query Server，负责作业管理。
资源管理的监控能够决定出：在哪个容器中将哪个应用“拉起来”，而在哪个容器里将其“下线”。
虽然该容器编排架构属于微信自研、且尚未对外开放，但是其调度能力已逐步开放到了腾讯云之上。
腾讯云提供了包括集群管理、资源调度、以及镜像仓库等方面的结合。其对应的产品包括 CCS（容器管理）、API 网关、以及分布式微服务的架构管理等。
微服务精细化运营
精细化运营要做到对资源进行“削峰填谷”。通过了解业务的特性，掌握每个业务峰值的不同时间，从而将资源尽可能控制在上图的蓝色线条附近。
例如：微信的游戏里有一个功能模块，在凌晨零点的时候开始新发礼品。此时该模块对于资源的需求会剧增，而同一时刻其他模块的资源消耗并不多。
因此我们就可以把该游戏发礼品的微服务部署到其他模块服务器资源之上，从而削除它的峰值，达到了错峰服务的效果。
我们在许多场景中会用到离线计算，如：各种日志分析、应用数据分析、以及人工智能方面的训练。
这些都是可以使用到离线计算的业务，多数不需要实时，它们都可以被部署在资源谷底的时候。
微服务的未来演进
我们采用微服务架构之后，有些问题也值得我们去认真思考：
- 微服务这么多，我们能否延用以往的 CMDB 方式进行有效地管理呢？特别是那些放在公有云端的微服务，如何将它们纳入现有的 CMDB 呢？
- 是否有更好的微服务管理工具，来实现服务可视化、消息跟踪和智能故障检测？
- 是否有微服务的应用商店，来帮助我们快速地开发各种应用？
熊普江，腾讯公司资深架构师 ，负责公司腾讯云技术、解决方案布道与技术架构评审等工作。腾讯公司级课程讲师，GITC 专家顾问，WOT 特约讲师，GOPS 金牌讲师。自 1997 年涉足互联网，曾服务美国 Supreme、太平洋网络、PPTV 等互联网公司，任网络运营总监、运维总监等职务。近 20 年互联网从业背景，对大型网络架构规划与建设，海量用户平台规划与运营技术支持，超大规模业务资源规划与技术架构管理优化有丰富的经验。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
