微服务架构实践分享（下）－－七牛首席布道师何李石

Posted 2021-04-14 极牛

本次分享来自于极牛x顶级VC技术Plus技术分享系列活动。

本次主题

面对上一节提到的微服务实践中的各种问题，分享下七牛内部是如何进行微服务部署实践和解决这些问题的。

---

七牛微服务部署

七牛有一个服务，是用来对客户的文件进行处理的，比如图片的缩放和裁剪，音视频的转码等，这个服务每天处理的请求在十亿到百亿级别。

举个图片缩放和打水印的例子：

大家可以看到这张图片，它把一张 640x960 的原图缩成了一张 400x400 的图，还在右下角打上了七牛 logo 的水印（通过管道）

一开始，它的架构是这样的：

量不大的时候，在几台物理机上部署一些服务就可以撑住，架构非常简单， FopGate 均衡的将流量分发到后端物理机的 worker 里面处理。缺点在于它无法感知后端物理机的宕机，只有在宕机之后让 FopGate 重试，发到另一台物理机去处理，后来对这个架构做了一个改进。

大家可以看下 slides 里面的注释，主要增加 Discovery 组件来对收集后端物理机的信息。同时增加 Agent 来做单机内 worker 的负载均衡。

这里面我再解释下 Agent 的功能，它收到文件处理指令后会从存储里面拉文件，并讲拉回来的文件和处理指令一并发给后端的 worker 去处理。

为什么不能让 worker 自己去存储里面拉文件呢？因为对于一个文件，可能有多种不同的处理操作，如果让具体干活的某个 worker 自己去拉，流量会比较大。Agent 拉回来之后可以把文件缓存下来。

这样的架构功能比之前强大，但是数据流和指令流夹杂在一起，系统复杂。并且当时只是简单的把图片和音视频处理的 worker 部署在一起，两者有任何一方过载的时候可能影响另一方的性能。

后来，我们进一步将单机内的负载均衡职责放到外面，让 Agent 和 Worker 部署在同一组逻辑集群内。同时，把音视频处理和图片处理的功能分开。

这里面由于部署的原因，Agent 和 Worker 捆绑在一起了，也就是说刚才那个问题反而在这里体现了，我拉文件的时候可能存在带宽的浪费。

从刚才讲到的 Agent 的职责可以看出，实际上它起了一部分缓存文件的作用，也就是说它是有状态的，而具体干活的 worker 是无状态的，把他们两个部署在一起不太合适。因为他们在升级或者崩溃的时候也都是一起生或者一起死。

然后进一步分离 Agent 和 Worker，这就是最终状态。

到了最终状态之后大家可以看出来，如果不考虑里面跑的具体业务，这四个服务的架构其实是一样的，都是最前端有一个负载均衡器，里面有具体的服务。这些服务可以随意的进行灰度升级、扩容和缩容。

有状态的 Agent 相对特殊点，需要保持状态。其实升级之后，文件可以重新拉取，只需要保证元信息保持下来就行了。

从最初的物理机部署到最后的高可用部署，有一个很大的转变，就是服务所依赖的「平台」变了。一开始是物理机，高可用需要自己去做，后来平台自己做了高可用。应用程序本身其实并没有多大变化，只是他们的运行方式变了。

也就是这样。

看到这么多容器，就不难理解之前说的微服务的几个挑战了：
1. 微服务带来内部通信成本的指数级增加。
2. 微服务应用往往意味着内部是一个巨大的分布式系统，如何测试是一个大挑战。比如我们的每天服务几百亿请求的存储和缓存服务。
3. 微服务之间也可能会有依赖关系，在部署的时候如何处理好这些依赖关系也存在挑战。 

针对这些微服务部署的挑战，我们构建了一个 PaaS 平台，来更方便的运行这些服务。

Q&A环节

Q 1: 微服务架构会导致数据分区，在数据的一致性上会面临挑战，对开发者而言，如何降低开发难度？ 

A：数据一致性是任何一个分布式系统本身应该保证的，跟是否采用微服务架构没太大关系，这里的挑战应该在于「如何做好一个分布式系统」。对于应用层开发者而言，数据的存储基本上都可以采用云服务，比如云存储和云数据库。

Q2: 微服务架构使得每个服务相对独立，测试一个基于微服务架构的应用也是很复杂的任务，有没有好的测试方式或工具？ 

A：服务功能单一之后，单个服务的功能更容易保证，只要把它们之间的边界定义好，同时降低依赖关系，理论上就更好测试。实际上微服务化后比较好的做法是尽量所有环节都自动化，而容器也让自动化测试更加方便。

Q3: 微服务使得维护和部署变得困难，那对一个创业公司而言，什么阶段引入微服务比较合适？

A：就是说从开发到灰度到上线，整个环节都能够通过内部和外部「微服务」串联起来。团队需要从一开始就规范流程，比如提交 commit 之后自动触发单元测试等一系列操作。

创业公司现在非常流行 MVP，Minimum Viable Product，最简可行产品的迭代方式。在这个过程中必然会有无数次的上线发布和回滚来回，一开始采用微服务的方式来规范技术栈是最好的选择，而众多云平台也让这个选择的成本降低了很多。

Q4: 微服务带来内部通信成本的指数级增加怎么解决呢？

A：微服务数量的指数增长必然带来通信成本的指数增长，这是所有方便部署微服务的云平台都面临的挑战，因此也是一个很大的问题，简单来讲我们通过自研的 SDN 来解决内网互通的问题。

Q5: 除了刚才的例子，七牛哪些服务采用了微服务？

A：我们现在有刚才讲到的图片和音视频处理服务采用微服务架构，为此我们构建了一个公有云平台，现阶段在正在将公司内大部分服务都迁移到这个平台上。

Q6: 七牛在实现微服务的时候是怎么收集日志的？是集中收集，还是返回到调用方的机器上呢？

A：为了配合这个公有云平台用户的使用，我们组建了一个大数据团队做日志的收集、汇聚和分析，以服务的形式提供给计算平台的用户使用。也就是说，部署在上面的服务只需要按指定的方式输出，比如输出到标准输出，就可以被收集起来，也能够享受到所有后续分析的便利。

查看上期分享请戳