瘟疫的生物学质数策略

    1976年2月美國新泽西州迪克斯堡新兵营中发生了一起猪（H1N1）亚型毒株引起的流感爆发事件

    1826年的第二次大流行中，它抵达阿富汗和俄罗斯然后扩散到整个欧洲

授予每个自然月内发布4篇或4篇以仩原创或翻译IT博文的用户不积跬步无以至千里，不积小流无以成江海程序人生的精彩需要坚持不懈地积累！

微服务架构在最近几年越来越火离不开架构本身的分工明确，很好的解决了代码的重用问题让开发效率更高。

本文将介绍微服务架构和相关的组件介绍他们是什么鉯及为什么要使用微服务架构和这些组件。本文侧重于简明地表达微服务架构的全局图景因此不会涉及具体如何使用组件等细节。

要理解微服务首先要先理解不是微服务的那些。通常跟微服务相对的是单体应用即将所有功能都打包成在一个独立单元的应用程序。从单體应用到微服务并不是一蹴而就的这是一个逐渐演变的过程。本文将以一个网上超市应用为例来说明这一过程

几年前，小明和小皮一起创业做网上超市小明负责程序开发，小皮负责其他事宜当时互联网还不发达，网上超市还是蓝海只要功能实现了就能随便赚钱。所以他们的需求很简单只需要一个网站挂在公网，用户能够在这个网站上浏览商品、购买商品；另外还需一个管理后台可以管理商品、用户、以及订单数据。

我们整理一下功能清单：

由于需求简单小明左手右手一个慢动作，网站就做好了管理后台出于安全考虑，不囷网站做在一起小明右手左手慢动作重播，管理网站也做好了总体架构图如下：

小明挥一挥手，找了家云服务部署上去网站就上线叻。上线后好评如潮深受各类肥宅喜爱。小明小皮美滋滋地开始躺着收钱

好景不长，没过几天各类网上超市紧跟着拔地而起，对小奣小皮造成了强烈的冲击

在竞争的压力下，小明小皮决定开展一些营销手段：

• 开展促销活动比如元旦全场打折，春节买二送一情人節狗粮优惠券等等。

• 拓展渠道新增移动端营销。除了网站外还需要开发移动端APP，微信小程序等

• 精准营销。利用历史数据对用户进行汾析提供个性化服务。

这些活动都需要程序开发的支持小明拉了同学小红加入团队。小红负责数据分析以及移动端相关开发小明负責促销活动相关功能的开发。

因为开发任务比较紧迫小明小红没有好好规划整个系统的架构，随便拍了拍脑袋决定把促销管理和数据汾析放在管理后台里，微信和移动端APP另外搭建通宵了几天后，新功能和新应用基本完工这时架构图如下：

这一阶段存在很多不合理的哋方：

• 网站和移动端应用有很多相同对业务发展的想法逻辑的重复代码。

• 数据有时候通过数据库共享有时候通过接口调用传输。接口调鼡关系杂乱

• 单个应用为了给其他应用提供接口，渐渐地越改越大包含了很多本来就不属于它的逻辑。应用边界模糊功能归属混乱。

• 管理后台在一开始的设计中保障级别较低加入数据分析和促销管理相关功能后出现性能瓶颈，影响了其他应用

• 数据库表结构被多个应鼡依赖，无法重构和优化

• 所有应用都在一个数据库上操作，数据库出现性能瓶颈特别是数据分析跑起来的时候，数据库性能急剧下降

• 开发、测试、部署、维护愈发困难。即使只改动一个小功能也需要整个应用一起发布。有时候发布会不小心带上了一些未经测试的代碼或者修改了一个功能后，另一个意想不到的地方出错了为了减轻发布可能产生的问题的影响和线上对业务发展的想法停顿的影响，所有应用都要在凌晨三四点执行发布发布后为了验证应用正常运行，还得盯到第二天白天的用户高峰期……

• 团队出现推诿扯皮现象关於一些公用的功能应该建设在哪个应用上的问题常常要争论很久，最后要么干脆各做各的或者随便放个地方但是都不维护。

尽管有着诸哆问题但也不能否认这一阶段的成果：快速地根据对业务发展的想法变化建设了系统。不过紧迫且繁重的任务容易使人陷入局部、短浅嘚思维方式从而做出妥协式的决策。在这种架构中每个人都只关注在自己的一亩三分地，缺乏全局的、长远的设计长此以往，系统建设将会越来越困难甚至陷入不断推翻、重建的循环。

幸好小明和小红是有追求有理想的好青年意识到问题后，小明和小红从琐碎的對业务发展的想法需求中腾出了一部分精力开始梳理整体架构，针对问题准备着手改造

要做改造，首先你需要有足够的精力和资源洳果你的需求方（对业务发展的想法人员、项目经理、上司等）很强势地一心追求需求进度，以致于你无法挪出额外的精力和资源的话那么你可能无法做任何事……

在编程的世界中，最重要的便是抽象能力微服务改造的过程实际上也是个抽象的过程。小明和小红整理了網上超市的对业务发展的想法逻辑抽象出公用的对业务发展的想法能力，做成几个公共服务：

各个应用后台只需从这些服务获取所需的數据从而删去了大量冗余的代码，就剩个轻薄的控制层和前端这一阶段的架构如下：

这个阶段只是将服务分开了，数据库依然是共用嘚所以一些烟囱式系统的缺点仍然存在：

1. 数据库成为性能瓶颈，并且有单点故障的风险

2. 数据管理趋向混乱。即使一开始有良好的模块囮设计随着时间推移，总会有一个服务直接从数据库取另一个服务的数据的现象

3. 数据库表结构可能被多个服务依赖，牵一发而动全身很难调整。

如果一直保持共用数据库的模式则整个架构会越来越僵化，失去了微服务架构的意义因此小明和小红一鼓作气，把数据庫也拆分了所有持久化层相互隔离，由各个服务自己负责另外，为了提高系统的实时性加入了消息队列机制。架构如下：

完全拆分後各个服务可以采用异构的技术比如数据分析服务可以使用数据仓库作为持久化层，以便于高效地做一些统计计算；商品服务和促销服務访问频率比较大因此加入了缓存机制等。

还有一种抽象出公共逻辑的方法是把这些公共逻辑做成公共的框架库这种方法可以减少服務调用的性能损耗。但是这种方法的管理成本非常高昂很难保证所有应用版本的一致性。

数据库拆分也有一些问题和挑战：比如说跨库級联的需求通过服务查询数据颗粒度的粗细问题等。但是这些问题可以通过合理的设计来解决总体来说，数据库拆分是一个利大于弊嘚

微服务架构还有一个技术外的好处，它使整个系统的分工更加明确责任更加清晰，每个人专心负责为其他人提供更好的服务在单體应用的时代，公共的对业务发展的想法功能经常没有明确的归属最后要么各做各的，每个人都重新实现了一遍；要么是随机一个人（┅般是能力比较强或者比较热心的人）做到他负责的应用里面在后者的情况下，这个人在负责自己应用之外还要额外负责给别人提供這些公共的功能——而这个功能本来是无人负责的，仅仅因为他能力较强/比较热心就莫名地背锅（这种情况还被美其名曰能者多劳）。結果最后大家都不愿意提供公共的功能长此以往，团队里的人渐渐变得各自为政不再关心全局的架构设计。

从这个角度上看使用微垺务架构同时也需要组织结构做相应的调整。所以说做微服务改造需要管理者的支持

改造完成后，小明和小红分清楚各自的锅两人十汾满意，一切就像是麦克斯韦方程组一样漂亮完美

春天来了，万物复苏又到了一年一度的购物狂欢节。眼看着日订单数量蹭蹭地上涨小皮小明小红喜笑颜开。可惜好景不长乐极生悲，突然嘣的一下系统挂了。

以往单体应用排查问题通常是看一下日志，研究错误信息和调用堆栈而微服务架构整个应用分散成多个服务，定位故障点非常困难小明一个台机器一台机器地查看日志，一个服务一个服務地手工调用经过十几分钟的查找，小明终于定位到故障点：促销服务由于接收的请求量太大而停止响应了其他服务都直接或间接地會调用促销服务，于是也跟着宕机了

在微服务架构中，一个服务故障可能会产生雪崩效用导致整个系统故障。其实在节前小明和小紅是有做过请求量评估的。按照预计服务器资源是足以支持节日的请求量的，所以肯定是哪里出了问题不过形势紧急，随着每一分每┅秒流逝的都是白花花的银子因此小明也没时间排查问题，当机立断在云上新建了几台虚拟机然后一台一台地部署新的促销服务节点。几分钟的操作后系统总算是勉强恢复正常了。整个故障时间内估计损失了几十万的销售额三人的心在滴血……

事后，小明简单写了個日志分析工具（量太大了文本编辑器几乎打不开，打开了肉眼也看不过来）统计了促销服务的访问日志，发现在故障期间商品服務由于代码问题，在某些场景下会对促销服务发起大量请求这个问题并不复杂，小明手指抖一抖修复了这个价值几十万的Bug。

问题是解決了但谁也无法保证不会再发生类似的其他问题。微服务架构虽然逻辑设计上看是完美的但就像积木搭建的华丽宫殿一样，经不起风吹草动微服务架构虽然解决了旧问题，也引入了新的问题：

• 微服务架构整个应用分散成多个服务定位故障点非常困难。

• 稳定性下降垺务数量变多导致其中一个服务出现故障的概率增大，并且一个服务故障可能导致整个系统挂掉事实上，在大访问量的生产场景下故障总是会出现的。

• 服务数量非常多部署、管理的工作量很大。

• 开发方面：如何保证各个服务在持续开发的情况下仍然保持协同合作

• 测試方面：服务拆分后，几乎所有功能都会涉及多个服务原本单个程序的测试变为服务间调用的测试。测试变得更加复杂

小明小红痛定思痛，决心好好解决这些问题对故障的处理一般从两方面入手，一方面尽量减少故障发生的概率另一方面降低故障造成的影响。

监控 - 發现故障的征兆

在高并发分布式的场景下故障经常是突然间就雪崩式爆发。所以必须建立完善的监控体系尽可能发现故障的征兆。

微垺务架构中组件繁多各个组件所需要监控的指标不同。比如Redis缓存一般监控占用内存值、网络流量数据库监控连接数、磁盘空间，对业務发展的想法服务监控并发数、响应延迟、错误率等因此如果做一个大而全的监控系统来监控各个组件是不大现实的，而且扩展性会很差一般的做法是让各个组件提供报告自己当前状态的接口（metrics接口），这个接口输出的数据格式应该是一致的然后部署一个指标采集器組件，定时从这些接口获取并保持组件状态同时提供查询服务。最后还需要一个UI从指标采集器查询各项指标，绘制监控界面或者根据閾值发出告警

大部分组件都不需要自己动手开发，网络上有开源组件小明下载了RedisExporter和MySQLExporter，这两个组件分别提供了Redis缓存和MySQL数据库的指标接口微服务则根据各个服务的对业务发展的想法逻辑实现自定义的指标接口。然后小明采用Prometheus作为指标采集器Grafana配置监控界面和邮件告警。这樣一套微服务监控系统就搭建起来了：

定位问题 - 链路跟踪

在微服务架构下一个用户的请求往往涉及多个内部服务调用。为了方便定位问題需要能够记录每个用户请求时，微服务内部产生了多少服务调用及其调用关系。这个叫做链路跟踪

我们用一个Istio文档里的链路跟踪唎子来看看效果：

Sevice Mesh相比于微服务框架的优点在于它不侵入代码，升级和维护更方便它经常被诟病的则是性能问题。即使回环网络不会产苼实际的网络请求但仍然有内存拷贝的额外成本。另外有一些集中式的流量处理也会影响性能

微服务不是架构演变的终点。往细走还囿Serverless、FaaS等方向另一方面也有人在唱合久必分分久必合，重新发现单体架构……

不管怎样微服务架构的改造暂时告一段落了。小明满足地摸了摸日益光滑的脑袋打算这个周末休息一下约小红喝杯咖啡。

谢谢大家的阅读原创不易，喜欢就点个赞这将是我最强的写作动力。如果你觉得文章对你有所帮助也蛮有趣的，就关注一下我的博客谢谢。