服务端架构的演变之路——以ShareREC服务端为例

本文是Mob开发者平台Java高级工程师周志鹏基于ShareREC服务端架构演进之路的分享。

文 / 周志鹏

概要

ShareREC是一款为手游提供录制分享功能的SDK；其服务端则是为SDK提供视频、用户、评论等相关数据计算及存储服务。

目前，ShareREC 支持Android、iOS、unity3d等，手游集成对应版本SDK后，可以直接免费使用ShareREC 整套后端视频托管计算服务。用户将不需要自己搭建视频托管服务，不需要维护视频的存储等。同时在Mob开发者平台官网后台，有一整套完整的ShareREC统计、分析等功能，助力用户打造视频录制、存储、托管一条龙服务。

整体架构概览

ShareREC服务端整体为分布式架构，支持弹性扩张及百万级并发请求。每一个应用开发者的视频等数据将独立分类存储，互不干扰。

业务架构概览

业务架构分层，自下向上依次为数据层、服务层、业务层、通信层。每一层职业清晰，边界分明，整体可用性高。各层都有相应的业务告警机制、日志收集等，为每一次请求保驾护航。

业务架构演变之路

上面讲到，在业务层有诸如用户模块、应用模块、视频模块等等。由于早期开发模式影响及为了快速响应市场需求，这些模块在初期以项目Module的形式放在一起的，可以理解成它们只是从代码目录结构上是分离的，但是从服务角度看却仍然是一个整体。

随着微服务架构的流行，这里有必要思考一下服务架构调整相关的事情，以下讲解侧重于理论。

微服务之我见

那什么是微服务呢？

微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

以上摘自网络描述，我个人理解：微服务是尽可能的将具有独立价值功能的且被多个其他业务依赖的代码，抽离出来独立部署并对外提供服务的架构。

了解微服务基本概念之后，接下来的问题在于如何“抽离”呢？

这里再来看一下上面ShareREC架构图中的业务层部分：

可能有人会说，你上面给的架构图已经很明显了啊，像“用户模块”、“应用模块”… 所有这些模块都单独放到一个独立部署的服务中就行了啊！

诚然，像这样每个小模块都单独抽离出来当然是可以的，但是。。。

你有考虑过运维人员的感受么？？

运维大哥会因为你的过于细分而维护的焦头烂额的！况且独立部署的机器资源成本也是不容忽视的！

那么，话说回来，既然不能每个小模块都抽离成一个独立服务，又不能整体作为一个单一的服务，那该如何划分所谓的微服务呢？

这里，我的个人观点是，没有绝对唯一的解决方案，因不同的业务场景需要划分的粒度也是有所不同的，但是再次引用我个人上面对于微服务的理解：

微服务是尽可能的将具有独立价值功能的且被多个其他业务依赖的代码，抽离出来独立部署并对外提供服务的架构

抽离成微服务的前提是：

• 有相对完整且独立价值功能
• 有多个（至少两个）业务依赖该功能

要同时满足上述两个条件，才有抽离成微服务的必要！

完整功能可以理解，那啥又叫“独立价值”？

假设你的项目中某个模块有一堆的工具代码，比如提供文件操作、日志操作、http操作等等，且这个模块被很多其他模块所依赖，那你会将这个模块抽离成“微服务”并独立部署对外提供服务吗？

显然，通常你只是把它当做一个工具jar包来供其他业务集成使用，因为这类仅仅靠简单CPU计算就能工作的模块，并不会产生实质的价值

一般的，有一些模块务必建议抽离成微服务，比如：数据库数据操作模块。

将数据库数据操作模块抽离成微服务原因有很多，比较重要的几点是：

• 数据库应该是私有化，需要被某个业务认领，其他依赖该数据的业务应该通过“主人”业务提供的数据接口间接对数据进行操作 （防止被绿帽子或者其他安全因素产生）
• 对任何互联网公司而言，数据服务才是最宝贵的，需要独立部署，单独维护。

好了，遵照以上几点，微服务边界相信大家已经有点自己的想法了。解决了应用的耦合、强依赖问题，那么接下来就要考虑一下服务的弹性扩容和缩容了！

微服务Docker化

Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。

以上描述引用自百度知道。

继续阅读之前，假设你已经足够的了解docker了，那么继续聊点理论化一点的东西吧（后续有其他专题会介绍具体实践应用）

微服务架构师对大应用进行合理的拆分，对众多的服务进行治理的过程。当我们服务治理已经足够清晰之后，不可避免的会面临流量问题，应用是否可以做到访问流量增长时能快速的水平扩容，提高整体负载能力，而在流量下降时快速的缩容，节省服务器资源呢?

在docker出现之前，要做到上面说的那样“智能"方便还是非常困难的！

抽象来看利用docker的swarm来管理容器集群大概是下面这样：

说明一下，图中的swarm节点并不是另外一个中间件或者额外的系统，它植生与docker 引擎之内，与宿主机同在，因此是没有额外的单点故障的。

所有的宿主机上的docker环境都可以看做是一个大的docker环境，借助于swarm的服务创建命令，可以快速的将指定数量的应用A部署到相应的机器上。并且都有某台宿主机上某个应用A容器挂了话，swarm会自动帮你在其他机器上拉起来一台，保证初始应用集群数量不变。

以前大家交付的是代码或者叫可执行程序，但是程序所依赖的执行环境却每次都要单独安装，而docker交付的是镜像，其中是可以包含你的程序所依赖的一切的！包括你钟爱的linux操作系统发行版！

关于更多docker细节，可以去网络上搜索。

结语

服务架构一直在不停的演变中，从早期的单体服务，到现在的微服务、Serverless 无服务架构、容器服务等等，未来必定有更多的挑战！ShareREC手游录像分享SDK还在成长的道路上，也必将经历更多，才能承受住大家的厚爱。