行业动态

微服务架构的演进

随着智能手机在移动互联网中的快速普及，中国互联网中心相关调查显示，通过手机上网的用户比例已达到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外包解决方案。 ， 咨询。