发布日期：2022-08-21 来源：https://www.tinymind.net.cn/articles/5dfab244810707 浏览次数：2714
如今互联网技术呈现出两方面的发展趋势：云化的趋势和微服务。两者相结合则更富挑战性，本次我将以微信为例和大家一起探讨。
本次分享分为三个方面：
微服务架构的演进
智能手机在移动互联网中的快速普及，中国互联网中心的相关调查表明：通过手机上网的用户比例已经高达 93% 以上；而整个中国的互联网渗透比例也已超过六成。
因此，我们所处的移动互联网时代的开发呈现出如下的特征：
移动互联时代全面来临
虽然在工作时仍然离不开电脑，但是我们使用手机来连接互联网的场景更为频繁。
由于手机的运算能力有限，手机更多地被用于展示或显示内容。大量功能化的计算处理显然需要依赖于云端。所以我们实际上处于一个瘦客户端的时代。
随着我们停留在移动互联网上的时间剧增，大量的数据也随之产生，特别是相较于传统 PC 时代，增长了数十倍、乃至数百倍。
这些大量的数据同样也需要在云端进行处理，因此我们对于云服务的能力也会有一定的要求。
硬件技术发展迅速，服务器性能越来越大。如今硬件的处理能力（特别是 GPU）发展迅速，服务器的处理能力也得到了迅速提升。
这都导致了单个应用或者单个功能模块很难消耗掉整台服务器的资源。为了提高多台服务器的资源利用率，我们需要将多个服务部署到同一台机器之上。
容器技术兴起，轻量协议支持成熟应用
在软件方面，新兴的技术包括：容器、Docker 和诸如 restful 之类的轻量协议，都加快了我们的开发与部署效率。
应用的云化逐渐普及
为了将服务放到云端，我们不再需要去买各种机器，而直接在云上运用各种资源来部署我们的服务。
该领域不仅是互联网企业的热点，其他传统企业，包括一些金融和医疗企业也都在往云端寻求探索方向。
开发模式转变
传统的单体式集中开发模式为：前端 Web→管理系统→数据库→操作系统→底层服务器。
这种从上到下的“纵切”方式势必导致了对于技术人才、硬件、网络、软件、以及技术的大量需求。
这些对于初创型企业来说，会存在全能人才难招、开发复杂、迁移与扩容难度大、无法快速的响应等困难。
因此我们需要在开发和运维方面转变思路，通过“横切”将底层资源和中间平台转包给 IaaS 和 PaaS 平台，仅集中精力在前端的业务应用上。
精细化运营转变
由于越来越多的服务都要经由云端处理，以通过各种容器来实现快速部署与扩展，因此我们必需使用精细运维，来实现对于资源的充分利用。
基于上述移动互联网时代的开发特征，一种适用于快速变化需求的微服务架构应运而生，同时它也催生了 DevOps 的概念。
它是一种敏捷的开发模式架构，能够让我们迅速地实现：编写规划→编写代码→构建测试→发布上线→部署应用。
近两年，微服务这个术语渐成热门词汇，但它不是一个全新架构，更不是一个包治百病的架构。
那么，微服务架构与单体式架构相比优势体现在哪？这些优势又给开发模式、运维带来哪些挑战？
微服务架构的特点与趋势
微服务架构的特点与趋势如下：
微服务架构解析
微服务架构解析：
微服务架构的优势
微服务架构有如下几个明显的优势：
微服务架构带来的挑战
下面是谈谈引入微服务架构时会碰到的各种挑战：
微服务架构下的运维思考
下面是我在微服务架构下的一些运维思考：
微服务架构运维的解决之道
下面先以微信为例，讲解它使用到微服务架构的地方，接着介绍我们在微服务容量管理方面的具体工作，然后给大家分享在监控部署调度上值得参考的地方，最后探讨我们在资源利用率上的精细化运营。
微信为什么要微服务云化
自 2011 年诞生以来，微信一直强调使用快速迭代、试错、纠正的敏捷开发模式，也就是我们常说的“小步快跑”方式。
在微信内部有四个“法器”，分别是：
大系统小做，不仅涉及到将海量系统中的模块变得更清晰，而且在物理环境中实现分开独立的部署，以便快速发现问题。
例如：一些公共服务的注册登录、LBS 的逻辑、和类似微信的摇一摇等方面，我们都将这些逻辑独立了出来。
让一切可扩展，此处强调两个方面：
在 2013 年到 2014 年间，微信的微服务模块数已超过了 5000 个，我们碰到过两个问题：
有基础的组件，把复杂的逻辑固化下来，成为基础性软件。在微信的后台会有几种不同的基础组件，大致包括：
微信微服务架构的应用与管理
我们对微信里的各个微服务应用场景进行了定义：
我们对微服务也进行了技术分层：
微信采用多地自治、园区互备的架构，城市之间的数据是相对独立的。除了少数账号全球同步以外，大部分业务都以电子邮件式的服务，各自有自身的环境在流转和通信。城市间的后备则使用公网的 UDP 通道。
在城市内，使用三园区的架构，每个园区都是一套独立的系统，从接入、逻辑、存储每一层都是完全独立的，并且可以互相为对方提供备份，多园区形成整体服务规模。
在园区内，由多机组成的 set，互为容错，包含它们的网络与电力也是独立的。这样的服务布局，不仅满足微服务架构，也考虑了容灾能力。
过载保护是一个非常核心的微服务架构特性，目的是确保核心服务可用。
它包括三个层次：
为了在微服务架构下实行较好的容量关系，微信做到了三个前提：
容量管理是为了更好地进行业务支撑，因此我们构建了需要支撑的业务与其容量之间的模型关系，从而有效地评估出那些有效的微服务所对应的容量。
如上图所示，下方的灰色线表示实际业务的容量，即业务量，如：请求量、调用量、以及用户数。
红色线表示在机器扩容或升级之后的现网容量。绿色线则表示最优容量，它比现网容量要高出 20%，以保证只是偶尔被触发。
当业务需求超过现有容量时，业务就可能出现不稳定或者无法提供服务的情况。而扩容则往往涉及到复杂的数学运算。
因此由于现实中资源的采购、部署与上架存在周期，不大可能完全达到该绿色曲线。
随着公有云被广泛地运用，我们基本上能够实现及时获取容量资源。当然要保证具有较好的业务支撑的话，应当具有容量的发现能力和适当的处理效率。
在实际进行容量评估的时候，可能会碰到如上图所示的“坑点”：我们可能会将容量误解为左边的线性关系。
在某些时候，使用量上升到 60% 之前还是处于线性，可一旦升至 65% 或 80% 时，就会维持那么多且再也上不去了，如右边的容量模型所示。
所以说容量评估的困难之处就在于：一个应用或一个微服务在使用资源时会受到诸如：CPU、内存、网络、以及磁盘 I/O 等多种因素的制约。
因此，我们应当去熟悉某个微服务主要消耗资源的关键点，以及它与其他资源之间的关系。
针对容量的评估，同样在微信中引入了压测。如图所示，我们有四种模拟测试的方案：
压测具有双面性，好的一面在于：有助于我们发现过去未曾注意的底层问题；不好的一面，则是在出现问题之后，我们可能无法快速地恢复，有时甚至并非将流量撤掉那么简单。
因为一旦某个服务崩溃了，则需要花时间和精力重新启动它。因此我们在做真实压测时，会特别注意上图所列的三点。
上图展示了过载保护的机制。当有更多的流量抵达时，过剩的流量会被直接拒绝掉，显然我们也可籍此测算出其真实的流量大小。
可见过载保护，或称快速拒绝是在微服务架构下做好容量管理的重要前提。如果没有该保护，将很难评估现网容量的门限。
微信实现了对于微服务的立体化监控，监控的内容包括：
这些在监控上都有一些数据来上报及展现。由于我们监控指标非常多，同时伴随着微服务的增多，其产生的报警数量也会呈爆炸式增长。因此需要有智慧化的运维，通过 AI 应用去收敛各种报警。
就监控能力而言，我们为每台机器都部署了 Agent。这些 Agent 的监控粒度比较密集，能够达到秒级监控。与此同时，它们的数据上报能力也较为迅速。
容器的编排是微服务的一个重要方面，不同于 Docker，微信采用的是自研的 svrkit 架构，它参考了 borg/yarn/k8s/mesos 等主流调度系统的特点，该容器调度的微服务覆盖率超过 80%。
微信的容器调度系统叫做 yard。如上图下方所示，它分为两层架构：
资源管理的监控能够决定出：在哪个容器中将哪个应用“拉起来”，而在哪个容器里将其“下线”。
虽然该容器编排架构属于微信自研、且尚未对外开放，但是其调度能力已逐步开放到了腾讯云之上。
腾讯云提供了包括集群管理、资源调度、以及镜像仓库等方面的结合。其对应的产品包括 CCS（容器管理）、API 网关、以及分布式微服务的架构管理等。
精细化运营要做到对资源进行“削峰填谷”。通过了解业务的特性，掌握每个业务峰值的不同时间，从而将资源尽可能控制在上图的蓝色线条附近。
例如：微信的游戏里有一个功能模块，在凌晨零点的时候开始新发礼品。此时该模块对于资源的需求会剧增，而同一时刻其他模块的资源消耗并不多。
因此我们就可以把该游戏发礼品的微服务部署到其他模块服务器资源之上，从而削除它的峰值，达到了错峰服务的效果。
我们在许多场景中会用到离线计算，如：各种日志分析、应用数据分析、以及人工智能方面的训练。
这些都是可以使用到离线计算的业务，多数不需要实时，它们都可以被部署在资源谷底的时候。
微服务的未来演进
我们采用微服务架构之后，有些问题也值得我们去认真思考：
京公网安备 11010102005907号
