重构系统的套路-微服务化

服务拆分

根据业务或组织架构进行基本服务拆分,每个服务实例会拥有专属的网络地址、独立的计算资源,并且独立部署。客户端通过访问服务实例的地址来调用服务 API。不同服务也可以相互调用。

统一配置管理

一个服务可能会跑多个实例,每个服务实例都会需要做配置。为了方便统一调整配置,我们可以把配置中心化,每个服务实例都去找配置管理器(Configuration Manager)拿配置。当配置更新的时候,我们也可以让服务实例再去拿新的配置。

命名服务

多服务实例带来的问题:网络地址(比如 IP)很容易因为扩容、维护而变动,调用者难以实时获知可用的地址。

鉴于此,我们可以把网络地址抽象成不容易变动的概念,比如给每个服务一个固定的名字。互联网使用 DNS 来解决这个问题,对应到微服务基建里面就是服务名册(Service Registry)。

每个服务实例在运行期间,都会以心跳的形式向服务名册发送注册信息,包括服务的 ID 、访问地址以及健康状况。

这样,需要访问服务的时候,客户端就可以先问服务名册拿可用的实例地址,然后再访问实例来调用服务。除了更好地定位实例地址,服务名册还可以在某些实例下线、维护或升级的时候把其临时从名册中去掉,让服务不断线。

服务之间的调用也是如此,先找名册拿网络地址,再进行调用。

网关

找名册要地址,然后调用服务 API,这些是每个客户端都会去做的琐事,我们完全可以把这些事情抽象、集中,把服务的 API 整合到一个大的中心点,然后把要地址和调用服务 API 这样的细节封装起来,所有客户端都只跟这个中心点对话,不再直接访问单个服务。

从结构上看,这个中心点把整个架构划分成了内外两部分,内部是所有的服务,客户端则在外部,中心点站在中间。它作为内外的唯一通道,被顺理成章地命名作“API 网关”(API Gateway),有时候也被称做“边缘服务”(Edge Service)。

API 网关作为唯一出入口,又占据了最前沿的有利位置,所以有时还会承载别的公共功能,比如我们马上会提到的鉴权。

鉴权和身份认证

鉴权(Auth)包括了两个部分:

  • 身份认证(Authentication)和权限验证(Authorization)。
  • 身份认证关心的是“你是谁”,权限验证关心的是“你能不能做某件事”。

身份和权限都是高度中心化的概念。

对于一个系统来说,用户的身份必须是统一的。

权限稍微复杂一点。和身份不同,权限通常分成两种类别:

  • 功能权限和数据权限。

这样的划分对应了现实世界中常见的权限模式:

  • 你的角色决定了你的职能,而职能范围通常由附加条件来限制。

明确鉴权中心化之后,我们就可以开发一个公用的鉴权服务,执行身份认证和权限验证。下一个问题是:谁来发起鉴权?

所有服务的调用都要求调用者明确自己的身份,所以自然身份认证越靠前越好。作为出入口的 API 网关自然是发起身份认证的不二之选。

权限验证则稍微复杂,完全值得另起一文详述。此处我们暂时假定权限验证也由 API 网关来发起。

消息队列

开发继续进行,一切风平浪静,技术上暂时没有什么问题。不过,业务上有一个问题需要解决。

比如,我们做一个在线商城,要求在订单成功创建的一刻,仓库就要启动备货和发货的流程。

问题是,订单和仓储是两个服务,不同团队在负责,而且从关注点来说,订单服务并不关心仓储相关的问题,所以订单服务不可能在创建订单的时候去主动通知仓储服务。仓储服务只能定时轮询订单服务,看看有没有新的订单。这不仅麻烦,而且实时性不够。

这就意味着我们需要再引入一个中心化的公共服务:

  • 消息中介(Message Broker)。

当某个事件发生的时候(比如用户激活成功、订单创建成功),服务可以朝消息队列发一条消息。而其他服务可以订阅这些消息,并针对这些消息做出反应。

比如,仓储服务可以订阅订单创建成功的消息。这样,订单成功创建后,订单服务将这个消息发到消息中介,消息中介通知仓储服务,仓储服务一看,就问订单服务要新的订单信息,最后,启动出库流程。

消息中介除了能广播事件之外,还能做异步调用。把同步的调用转化成异步的回调。针对调用时间长和不要求实时结果的调用,可以增加性能,提升体验。

前后端分离

支撑一个业务有前后两端的研发工作,二者是不同步的。 前端由业务流程和设计来驱动,希望按顺序产出;后端则由业务资源和建模来驱动,希望按模块来产出。

比如说,前端常常会因为设计的原因调整自己需要的字段,而后端从建模的角度并没有这个需要,也没有动力频繁地去跟随前端的调整,使得前端不得不在不稳定的网络条件下传输多余的信息,占用了宝贵的网络带宽。

此外,前端呈现某个业务步骤的时候,有两种信息不属于当前必备信息,但常常需要和必要信息一起展示。一种是状态信息,比如当前的登录状态和用户名,短消息的数量等等。 一种是垂直相关的信息,比如在展示文章的时候顺便展示一下相关的文章。

这就要求前端在调用主服务的同时还要再调用多个不同的服务。且不说这些服务有可能会有调用超时、出错的可能,仅仅是多出来一堆异步请求,就已经足够让前端效率降低一大截了。

在微服务体系下,这些问题更加严重,因为现在不仅仅是前后端的差别,不同服务还由不同团队负责。这些团队的诉求和日程不一,很难做到前端所需要的快速响应。

这些问题和麻烦可能会催生一个“缓冲带”,比如后端出专人来负责对接前端的需要,或者前端派驻一个人到后端来谈需求。按康威定律,这种沟通体系,久而久之,很容易以软件的形式沉淀下来,形成一个专属的中间层。

  • 第一是解耦前后端的工作,降低相互的影响。前端需要的东西可以写在中间层里,让它频繁变化也没有关系。后端如果还没有准备好,前端也可以在这一层模拟假的数据,不至于被阻塞。
  • 第二则是提升前端的运行效率。前端可以把所需要的多个服务的东西统一汇总,一次拿完,免得发多个请求。

放置的位置则在 API 网关之内,让它可以享有 API 网关所带来的好处和保护。

最后是维护问题。按照“谁主张,谁举证”的原则,既然有了这个中间层,好处让前端得了,那么,理论上应该由前端来维护。

这样,一个主要为前端服务的中间层就定义好了。不同类型的前端(桌面、移动)可能会有不同的需要,为了避免中间层的碎片化,我们可以让各个中间层都特定的前端类型紧密耦合,比如桌面专用、移动专用。如此,每个中间层都像是某类型前端的专享后端,所以“前置后端”(Backend-for-Frontend,简称 BFF)也因此得名。

提高服务容错

现在,调试也方便了,我们又继续开发。一开始没有什么问题,但部署到预生产环境的时候,又一个问题出现了:

  • 整个体系的容错度很低。一个小错误容易被层层传递和放大,导致整个体系的崩溃。

我们都知道,编程最麻烦的就是远程调用。本地调用大部分时候结果是“成功”或“失败”,但远程调用则很可能是“无响应”。“无响应”有可能是正常的,对方可能稍后会给你结果,也可能是因为对方已经死了,没法给你响应。最坏的结果,就是门口挤满了人,大家都在等你给结果,而你也在等别人给结果,资源全部占用来等,什么也做不了。

不过,远程调用是无法避免的。在微服务体系中,这个问题被进一步放大。这是因为微服务的模块化以服务为单位,而每个服务独立部署和运维,使得服务之间的调用成了家常便饭。

在这种严峻的情况下,我们必须从架构上尽量提高整个服务体系的容错度,让个别服务的问题不至于影响到全局。

具体的做法,则是给远程调用加一个熔断阈值检查,当调用超时次数超过阈值时,就不再调用,直接返回错误。过一段时间之后,再把阈值恢复,尝试继续调用,重复前面的过程。这个机制就是回路熔断,而这个工具则是回路熔断器(Circuit Breaker)。

除了隔离已经出错的服务实例,熔断器还有一个重要的功能是提供备用方案。虽然我们把所有业务都拆成了服务,但服务有高低贵贱之分。有一些服务属于关键服务,一旦出问题,则整个流程无法继续,有一些则属于分支服务,即便错了,也不会影响大局。

比如说,购买商品的时候,常常会根据用户的习惯和当前正在购买的东西做一些推荐。负责推荐的服务出问题的话,大不了就不推荐了,不应该影响用户正常的购买流程。

同理,如果是在线点餐的地址定位服务出问题了,我们也应该允许用户手动选择餐厅进行点餐——体验虽然不佳,但至少正常的流程仍然可以走完。基于这个考虑,熔断器应该为非必要的服务调用提供备用方案,尽量保证核心流程的顺畅。

提升服务弹力

要正式上线,我们还必须做好负载均衡(Load Balancing,下简称 LB),提升整个服务的弹性。要做负载均衡,从理论上有两种方式:

  • 客户端负载均衡(Client-Side LB):由客户端来决定如何分散请求。
  • 中间方负载均衡(Mid-Tier LB):由 DNS、网关等中间方来决定如何分散请求。

现在,服务名册中已经有了服务及其对应的实例地址列表,所以客户端的负载均衡最简便的方式就是把地址拉下来,然后依次或者随机选择可用的地址。

中间方的负载均衡则选择面较多,从最外层的 DNS 到网关都可以不同程度地去按需要去做。

基础设施

在做扩展时,架构师应该注意区分哪些东西应该中心化,哪些东西应该由服务自行决定。 比如说,在本文提到的基建之中,(几乎是)强制完全中心化的模块有:

  • 配置管理
  • 服务名册
  • 消息队列

其中,配置管理和服务名册是所有服务都需要的基础设施,必然需要统一。消息队列和日志收集都是为了跨服务的操作和追踪,也必须中心化。

半中心化的模块则有:

  • 路由
  • 鉴权

路由和鉴权都必须统一,我们前面讨论过。

不过,微服务可能会向外界暴露“自用”和“客用”等多套公共 API(比如快递公司内部使用的物流 API 和开放给第三方使用的物流 API),所以可能会有两个 API 网关,对应会有两套 API 目录和两套鉴权体系,所以,它们是“半中心化”。

这些都是中心化、半中心化的选择范例。每一次中心化的选择都可能会让整个架构变得死板,失去灵活性,所以,我们在设计和扩展基建的时候应该特别注意这个问题。

除了中心化的选择之外,架构发展的另一个关注点,是让业务保持“黑盒”。

我们把每个服务之间的关联抽取了出来,也把权限的定义和验证抽取了出来,每个服务变得简单而纯粹,成了“纯业务式服务”,等同于一个仅包含了业务规则的黑盒。这样,不管服务和模块再多,也没有影响。业务的重用性也很高。

总而言之,搭建好了微服务的必要设施之后,剩下的就要根据实际情况和项目经验来继续调整了。比如,我们可能会选择把很多功能合并到一层,以避免过度分层所带来的不必要的性能损失,或者对整个基建进行一些细节微调。只要把控好“中心-自理”和“业务-非业务”之间的关系,这个基础设施就能健康地发展。

总结

微服务组件(按请求流中的出场顺序):

  • 配置管理:配置集中管理。
  • API 网关:对外的 API 总目录;API 依赖关系;发起鉴权。
  • 服务名册:服务的注册和发现。
  • 鉴权服务:提供鉴权服务:认证身份,验证功能权限。
  • 前置后端:按前端的需求拆解请求、调用服务,并汇总、转换结果。
  • 消息中介:全局通知机制;异步调用机制。
  • 回路熔断:隔离出问题的服务并等待其恢复;提供备用方案。
  • 负载均衡:避免服务过载。

原文发布于微信公众号 - 服务端技术杂谈(ITIBB2014)

原文发表时间:2018-05-27

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏杨建荣的学习笔记

Greenplum数据仓库迁移小记

迁移无小事,所以从开始计划将公司的Greenplum集群迁移,到最后落地,整个过程虽然说不上是波折,但是也算是有不少的故事,各种准备和协调。

2093
来自专栏FreeBuf

HTTP2.0协议被曝4个高危漏洞,可致服务器崩溃

如果你认为HTTP2.0协议比标准HTTP(超文本传输协议)更安全,那你就错了。有研究人员花费4个月的时间在HTTP2.0协议中发现4个漏洞! 去年2月,谷歌把...

2758
来自专栏云计算-私有云

Windows Server 2019前瞻

十一假期马上就过完了,不知道各位小伙伴玩的怎么样啊,是否有遇到“人在囧途”或者是否看到了处处大海。微软于2018年9月24日-28日在美国召开了Ignite 2...

1.4K0
来自专栏FreeBuf

Google Play商店漏洞:黑客可远程在你的安卓手机上安装恶意APP

安全研究人员发现Google Play商店中两个严重安全漏洞,可以允许攻击者远程在用户的安卓设备上安装并下载恶意APP(应用)。 Metasploit框架的技术...

1927
来自专栏架构师之路

秒杀系统架构优化思路

《秒杀系统架构优化思路》 上周参加Qcon,有个兄弟分享秒杀系统的优化,其观点有些赞同,大部分观点却并不同意,结合自己的经验,谈谈自己的一些看法。 一、为什么难...

3338
来自专栏PhpZendo

事件驱动架构设计

这篇文章是 软件架构演进 一个有关 软件架构 系列文章中的一篇。这些文章,主要是我学习软件架构、对软件架构的思考及使用方法的记录。相比于这个系列的前几篇文章,本...

5622
来自专栏FreeBuf

设计缺陷将导致亚马逊Echo变身成为监听设备

MWR的安全研究专家发现亚马逊Echo存在一个物理攻击漏洞,该漏洞将允许攻击者获得设备的root shell(设备底层为Linux操作系统),然后安装恶意软件,...

37815
来自专栏恰童鞋骚年

《大型网站技术架构》读书笔记四:瞬时响应之网站的高性能架构

此篇已收录至《大型网站技术架构》读书笔记系列目录贴,点击访问该目录可获取更多内容。

1032
来自专栏养码场

找工作太麻烦?造个机器人吧!

这是基于go语言编写的一款boss直聘机器人软件(牛人版)。附上Python版本, 无需配置Go环境, 我会提供windows和macos的可执行程序。不喜勿喷...

864
来自专栏数据和云

静默错误:Oracle 数据库是如何应对和处理的 ?

说明:关于本文提到的所有参考文档,一律上传分享,关注本公众号回复 122arch 获得。

1202

扫码关注云+社区

领取腾讯云代金券