微服务架构的演进

随着智能手机在移动互联网中的快速普及，中国互联网中心相关调查显示，通过手机上网的用户比例已达到93%以上； 而整个中国的互联网普及率也已经超过了60%。

因此，我◥们所处的移动互联网时代的发展呈现出以下特点：

移动互联网时代来临

虽然我们在工作中仍然离不开电脑服务器运维，但我们使用手机上网的频率更高了。

由于手机的计算能□力有限，手机更多的是用于显示或显示内容。 大量的函数计算过程显然需要依赖云端。 所以我们实际上处于瘦客户端时代。

随着我们花在移动互联网上的时间急剧增加，也产生了大量的数据，尤其是与ㄨ传统PC时代相比，增长了几十倍甚至上百倍。

这些大量的数据也需要在云端进行处理，所以我们对云服务的能力也有一定的要求。

硬件技术日新月异，服务器性能越来越大。 如今，硬件（尤其是GPU）的处理♀能力飞速发展，服务器的处理能力也得到了飞速的提升。

这就造成了单个应用或者单个功能模块很难消耗◣掉整个服务器的资源。 为了提高多台服务器的资源利用率，我们需要在同一台机器上部署多个服务。

容器技术兴起，轻量级协议支撑成熟应用

在软↓件方面，新兴技术包括：容器，以及诸如此类的轻量级协议加速了我们的开发和部署效率。

应用云化正流行

为了将服务上云，我们不再需要购买各种机〗器，而是直接使用云上的各种资源来部署我们的服务。

这个领域不仅是互联网公司的热点，其他传统公司，包括一些金融和医疗公司，也在寻求在云端探索方向。

发展模式转变

传统的单体集中式开发模式是：前端Web→管理系统→数据库→操作系统→底层服⌒　务器。

这种自上而下的“垂直切割”方式必然导致对技术人才、硬件、网络、软件、技术的大量需求。

对于初创企业来说，会存在全能型人才招揽难、开发复杂、迁移扩■张难、反应不快等问题。

因此，我们需要在开发和运维方面转变思路，通过“横切”将底层资源和中间▽平台分包给IaaS和PaaS平台，只关注前端业务应用。

精♀细化运营转型

随着越来越多的服务被云端处理，通过各种容器实现快速部署和扩展，我们必须通过细粒度的运维来实现资源〗的充分利用。

基于上述移动互联网时代的发展特点，适应快速变化需求的微服务架构应运而生，同时也催生了.NET的概念。

它是一种敏捷开发模型架构，可以让我们快速实现：编写规划→编写代码→构建测试→发布上线→部署应用。

近两年，微服务这个词逐渐成为一个流♂行词汇，但它并不是一个新的架构，更不是包治百病的架构。

那么，微服务架构相比单体架构有哪些优势呢？ 这些优势给开发模式和运维带来了哪些挑战？

微服务架构的特点和趋势

微服务架构的特点和趋势如下：

为了在与其他微服务打交道时使用统一的接口，微服务也进行了各种▂封装。

另外，当多个微服务共存时，同一个服务会有多个运行副本，因此具有很高的容错性。

微服务架构分析

微服务架构分析：

微服务架】构的优势

微服务架构具有以下明显优势：

微服务架构带来的々挑战

下面谈谈在引入微服务架构时会遇到的各种挑战：

微服务架构下的运维思维

以下是我对微服务架构下运维的一些思考：

微服务架构运维解决方案

下面我们以微信为例，说明它在哪些地方使用了微服务架构，然后介绍了我们在微服务容量管理方面的具体工作，然后分享给大家监控部署调度的参考点，最后讨论一下我们的资源利用。 精细化运营，提质增效。

微信为什么要用云端的微服务？

自2011年诞生以来，微信一直强调◥采用快速迭代、试错、修正的敏捷开发模式，也就是我们常说的“小步快跑”。

微信里有四大“神器”，分别是：

大系统的小工作，不仅要让庞大系统中的模块更加清晰，还要在物理环境中实现分离独立部署，快速发现问题。

比如：一些公共服务的注册登录，LBS的逻辑，微信的摇一摇等，我们把这些逻辑分离了。

为了使一切都具有可扩展性，这里强调两个方面：

2013年到2014年，微信微服务模块数量超过5000个。 我们遇到了两个问题：

有基础的组件，将复杂的逻辑固化，成为基础软件。 微信后台会有几个不同的基础组件，大致包括：

微信微服务架构应用与管理

我们在微信中定义了各个微服务应用场景：

我们还有分层的◢微服务：

服务布局

微信采用多区域自治、园区互为备份的架构，城市间数据相对独立。 除了少数账户的全球同步外，大部分业务都是以邮件服务为主，各有各的╳流通和交流环境。 城市之间的备份使用公网的UDP通道。

在城市中，采用三个ξ园区的架构，每个园区都是一个独立的系统，每一层在接入、逻辑、存储上完全独立，可以相互备份服务器运维，多个园区形成一个整体的服务规模。

在校园里，多台机器组成的集合是相互容错的，包括它们在内的网络和电源也是独立的。 这样的服务布局，既满足了微服务架构，又考虑了容灾能力。

过载保护

过载保护是一个非常核心的微服务架构特性，用来保证核心服务可用。

它由三个层次组成：

在Ψ这种情况下，需要有一个反馈机制。 如上图所示，整个系统基于反馈，整个拒绝信息在整个过程中传递。 上图右侧是几个典型的服务。 从一个CGI调用一个后台↘服务，然后调用另一个后台服务，系统会在CGI层面传递它的重要性。

回到前端调用服务A和B的例子，使用这样的重要性转移可以直接拒绝20%的相同用户的请求，有效解决了单个服务轻微过载的问题。

容量管理

为了在微服务架构下实现更好的容量关系，微信做到了三个前提：

容量管理是为了更好「的支持业务，所以我们在需要支持的业务和容量之间建立模型关系，从而有效的评估那些有效的微服务对应的容量。

如上图所示，下方灰色←线表示实际业务容量，即业务量，如：请求量、调用量、用户数。

红线表示机器扩容或升级后的现有网络容量。 绿线代表最优容量，比现有网络容量高出20%，保证只是偶尔触发。

当业务需求超过现有容量时，可能会↑导致业务不稳定或无法提供服务。 另一方面，缩放通常涉及复杂的数学运算。

因此，由于现ζ实中资源的采购、部署和上市存在周期性，完全达到绿色曲线的可能性不大。

随着公有云的广泛使用，我们基本上可以及时获取容量资源。 当然，如果要保证良好的业务支撑，就应该具备容量发现能力和合∞适的处理效率。

在实际评估容量时，可能会遇到如上图所示的一个“坑点”：我们可能会将容量误认为是左边的线性关系。

在某些时候，使用率在上升到 60% 之前是线☆性的，但一旦达到 65% 或 80%，它就会保持不变，再也不会上』升，如右侧的容量模型所示。

因此，容量评估的难点在于应用程序或微服务在使用资源时会受到CPU、内存、网络、磁盘I/O等多种因素的制约。

因此，我们应该熟悉微服务主要消耗资源的关键点以及它与※其他资源的关系。

对于容量评估，微信也引入了压力测试。 如图所示，我们有四种场景进行mock测试：

压力测试有两个方面。 好的一面是它可以帮助我们发现过去没⌒有注意到的潜在问题； 不好的一面是出现问题后，我们可能无法快速恢复，有时甚至连撤回流∏量都没有那么简单。

因为一旦一个服务崩溃了，要重新启动它是需要时间和精力的。 所以我们在做真正的压测时，会特别注意上图中列出的三点。

上图显示了过载保护的机制。 当更㊣　多的流量到达时，会直接拒绝多余的流量。 显然，我们也可以以此来衡量真实的流量大小。

可见，过载保护，或者说快速拒绝，是微服务架构下进行容量管理的重要前提。 如果没有这种保护，将很难评估现有网络容量★的阈值。

微服务监控

微信实现微服务的立体监控，监控内容包△括：

这些都有一些数据要在监控中上报和显示。 由于我们的监控指标非常多，随着微服务的增多，它们产生的告警也会爆发式增长。 因此需要智能运维，通过AI应用汇聚各种〓告警。

就监控能力而言，我们为每台机器都部署了Agent。 这些Agent的监控粒度比较密集，可以做到秒级监控。 同时，他们的数据上ζ　报能力也比较迅速。

业务部署和调度

容器编排是微服务的一个重要方面。 与微信采用自【研架构不同的是，它参考了borg/yarn/k8s/mesos等主流调度系统的特性。 容器调度微服务覆盖率超过80%。 %。

微信的集装箱调度系统叫做堆场。 如上图底部所示，分为两层架构：

资源管理∴的监控可以判断：哪个应用在哪个容器中被“拉起”，哪个应用在哪个容器中“下线”。

虽然容器编排架构是微信自研，尚未对外开放，但其调度能力已经逐步向腾讯云开放。

腾讯云提供集群管理▓、资源调度、镜像仓库的组合。 其对应产品包括CCS（容器管理）、API网关、分布卐式微服务架构管理等。

微服务精细化运营

精细化运营要实现资源“削峰填谷”。 通过了解业务的特点，把握每个业务高峰的不同时间点，可以将资源控制在尽可能接近上图蓝线的位※置。

比如：微信小游戏里有个功能模块，半夜发新礼物。 这时候模块对资源的需求会急剧增加，而同时其他模块的资源消耗并不多。

因此，我们可以将游戏送礼的微服务部署到其他模块服务▅器资源中，从而切断其峰值，达到错峰服务的效果。

我们在很多场景下都会用到离线计算，比如：各种日志分析、应用数据分析、人工智能训练等。

这些都是可以做离线计算的服务，大部分不需要实时，都可以在资①源最低点的时候部署。

微服务的未来演进

在我们采用微服务架构之后，有一些问题是值得我们认真思考的：

整理/夏立成 上海蓝梦创始人兼CEO，湖北IT公司副总裁，致力于以IT外包网络维护服务赋能企业客户发展，帮助企ω　业客户创新、迭代、进化。

蓝梦成立于上海，致力于提供IT外包、弱电工程（网络布线、机房建设、门禁考勤、视频监控、电话交换机、多媒体会议室）、系统集成（建网、网络改造、WIFI覆盖）企业客户、数据备份、病毒防护、文件权限、虚拟化等）、云服务（微软云、阿里云、企业邮箱等）“一站式”IT外包解决方案。 ， 咨询。