Service Mesh实践指南
周晶
微博平台研发技术专家，高性能OpenResty开发框架Vanilla作者。
立即订阅
6496 人已学习
课程目录
已更新 6 讲 / 共 6 讲
01 | 我们高呼的下一代微服务 Service Mesh 到底是什么？
02 | 从单体应用到 Service Mesh 的曲折历程
03 | 异构系统跨语言服务化初探
04 | 详解 Service Mesh 的事实规范
05 | Service Mesh 的请求路由流程分析
06 | 面向未来的思考：泛服务化与 Service Mesh
Service Mesh实践指南
登录|注册
02 | 从单体应用到 Service Mesh 的曲折历程
周晶 2018-03-18
内容概要
技术支撑着业务高歌猛进，业务增长反过来又驱动着技术不断向前演化，这是每个互联网公司发展过程中不变的旋律。作为全国最大社交媒体网站的微博更是如此。
从 2009 年上线至今，微博架构经历了从最初的单体应用到后面的 RPC 服务化、容器化、混合云架构以及现在的跨语言服务化和 Service Mesh 等诸多阶段，架构演变支撑着微博业务的一次次华丽转身，也见证了微博的飞速成长。
那么，微博架构是如何从一开始的单体应用一步步成长为今天的庞大规模？作为国内最早落地 Service Mesh 的公司，微博为什么要选择做 Service Mesh，具体又是如何做的？这是本系列文章将试图回答的问题。
首先，我会结合微博架构演进的历程向你展示当前微博架构的整体概貌。在这之后，我将聚焦于微博在 Service Mesh 方面的具体落地实践，为你详细讲解微博自研的服务网格 WeiboMesh 从 0 到 1 的成长历程。当然，其中也会有我自己对架构演进的一些思考。
下面，我们进入正题。
在业务发展的每个阶段，面临的问题都不尽相同，而问题又有各种优先级，这就难免为了解决某些较为迫切的问题而引入一些当时不 Care 的问题，这也是日常架构演化过程中难以避免的魔咒。
鱼和熊掌不可兼得，所以架构演化的真谛就在于各种方案评估中的利弊权衡，在以业务为重的前提下进行正向演化。
那么，微博各个发展时期的架构又是如何演化的呢？
业务初期：单体架构
微博发展初期，用户规模高速增长，伴随而来的还有不断涌现的新业务，因为你不知道哪个今天还名不见经传的业务明天就会摇身一变成为备受瞩目的核心业务，大家就像在白纸上疯狂试错。这个时候，快速开发上线才是当务之急。
为了达成这个目标，我们对整个系统做了优良的模块化设计，每个业务作为一个独立的模块，保障业务能独立开发、发布并快速上线。
同时我们自研了容器框架 Cedrus，并在接入层实现了一些通用的逻辑，比如提供统一的认证、频次控制、黑白名单、降级开关、配置服务等功能。平台服务内部则通过 Jar 包的方式依赖调用，对外暴露 API 接口。
在部署方面，我们采用大服务池整体部署的方案，这样一来我们可以更合理地利用资源，避免为每个项目每个模块单独配置资源。
这种单体架构的好处在于资源利用更合理，通过 Jar 包应用来完成的本地服务调用不仅更直接，性能也更高，模块之间开发也相互独立，很多通用的前置逻辑被统一剥离出来后，业务的同学只需要关注自己的逻辑实现就可以了。
当然，单体架构的缺点也很突出，最主要的就是耦合。项目之间强耦合带来了一系列问题，比如升级困难，回归测试非常难做，以及随着业务模块的增多，模块之间的依赖解决困难等问题，此外还有各种 Jar 包冲突，越往后功能越加臃肿，业务变更十分吃力。这时候，就必须考虑做拆分了。
业务稳定期：服务化改造
要对当时规模已经十分庞大的微博平台做拆分是一件极具挑战的事情，好在当时微博业务的发展已进入稳定期。这就是我之前所说的，在每个发展阶段我们所面临的问题都不尽相同，如果说前期大规模的单体架构是为了解决当时业务的温饱问题，那么以系统拆分为出发点的服务化改造就是要做到不但要温饱，还要吃得好。
我们希望通过架构改造来达到保证服务高可用的同时实现业务解耦的目的，以便更好地支撑业务发展。如何做到这一点？
我们主要从业务模块拆分方面来考虑，基于我们之前模块化的单体应用架构，按业务模块拆分是最自然也最容易想到的方案。我们只需要把以往基于 Jar 包依赖的大一统平台按照业务模块做拆分然后独立部署，即可达到业务解耦的目的。
RPC 服务化
但是拆分之后服务之间依赖的问题如何解决？我们当时面临两种选择，一种是提供 HTTP 的 RESTful 接口，一种是使用 RPC 提供远端过程调用。
RESTful 接口的好处在于 HTTP 是明文协议，开发调试比较方便，RESTful 接口描述也足够简单。但缺点也很突出，HTTP 协议本身比较臃肿，我们内部服务的依赖主要解决数据可靠性传输的问题，并不需要那么多无用的请求头。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《Service Mesh实践指南》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(8)
PandaWeiboMesh 跟 istio 的对比优点2018-12-20 2
wesleydeng在一台机器上有多个应用进程的情况下，weibo mesh如果一对一部署，跟应用进程的绑定关系怎么维护？有使用docker这样的容器技术来简化的部署方式么2018-07-11 2
灯下尘本机agent是独立部署的，还是侵入到服务代码里。2018-10-12 1
keyboard_chen_-如果一台机器上有多个应用进程，weibo mesh进程是几个?一对多还是一对一作者回复: 我们推荐一对一的部署方式，通常不同的应用所依赖的服务并不完全一样，mesh 需要订阅应用依赖的服务，不过一对多的部署也是支持的。
2018-04-18 1
goder这个是借鉴了Spring cloud的sidecar思想吗作者回复: sidecar 的思想我们倒是没有考究它起源于何处，很多架构设计里都有这个思路，算是一种常见的部署方式，我们这里是在内部跨语言服务化的改造过程中逐步解决各种问题后演化而来的，中间态是一个 motan agent，sidecar 的说法来自 Service Mesh 的通识实现与实施规范，比如 早期的 Linkerd、Envoy等
2018-03-28 1- Thomas YangBFF不提供给别的服务调用可以一对多只做正向代理2019-07-26
梦朝思夕请求双发是什么含义，可以解释一下吗2019-01-17
9jay能详细讲下也好的是如何拆分的吗2018-08-31
收起评论