阅读 2080

微服务不是全部,只是特定领域的子集

更多精彩文章。

《微服务不是全部,只是特定领域的子集》

《“分库分表" ?选型和流程要慎重,否则会失控》

这么多监控组件,总有一款适合你

《使用Netty,我们到底在开发些什么?》

《这可能是最中肯的Redis规范了》

《程序员画像,十年沉浮》

最有用系列:

《Linux生产环境上,最常用的一套“vim“技巧》

《Linux生产环境上,最常用的一套“Sed“技巧》

《Linux生产环境上,最常用的一套“AWK“技巧》


大家都在学SpringCloud,貌似学会了SC就牛逼哄哄,感觉不得了的样子。但微服务,在整个企业级应用中,只占了一小部分。微服务引入的问题比解决的问题还要多,你会遇到各种各样的bottleneck。

微服务解决的是计算节点的问题,然而根源却在存储节点。当业务规模变得越来越庞大,存储、编码、管理都会成为问题。

接下来我们谈一些放之四海而皆准的道理,不需要贴上"XX公司最佳实践"之类的标签。

下面是一张因数据扩张引出的微服务相关的图,简约但不简单。中小型公司只要有这些元素,就能玩的很好;大点的公司,因为规模太大,每个组件都会遇到瓶颈,所谓的专项的优化并不能脱离它的本质。

那我们开始。

注意,这张图仅是主要数据路径,一个子集,其他的包括CDN、通讯层等,不在此列。

这张图并不包含某个特定领域的具体架构,属于一个整体性的概括。我们从数据库容量的瓶颈说起,看一下微服务在其中的比重。

数据库

用户数据要存储,就存在数据库。过去这么多年,NoSQL并不能消除开发人员的恐惧,所以,MySQL之类还是大多数公司的首选存储。

假设你的业务增长的很好,这个就有意思多了。项目开始,你的sql玩的越6,那么给后人埋的坑,越多。因为sql的功能太丰富了,一不小心,就炫技了。你会发现,林子越大,对sql的规范要求越高。一些官宣的特性,在公司内是严格禁止的。

市场发展很好,终于来报应了。以前的技巧变成了现在的累赘。慢查询、全文扫描,招招毙命。想要加缓存,结果发现无从下手;想要分库分表,结果发现表关系错综复杂。

小表和宽表

所以第一步,还是得去填坑。一个超过3个表的联合查询业务,大概率是不合理的。在加缓存和分库分表之前,还是得重新设计一下数据表。

忘掉什么数据库范式,我们将存在两类表:小表和宽表。

小表提供了最基本的数据,可能一个简单的KV就完成了。一些联合查询,是直接可以在程序里进行循环拼接的。程序里循环1000次10毫秒的查询,比单次查询耗费6秒要强的多。这就是分布式系统的特点,小耗时的批量查询,比hang在那里更加有生命力。

宽表通过冗余的方式,提供了某个重要功能常用的分析数据。这种表的字段一般都特别多,在写入时通过拼接获取冗余数据,一般用在读多写少的场景。

完成了这一步,接下来的工作才能进行。

分库分表

《“分库分表" ?选型和流程要慎重,否则会失控》中,详细的说明了分库分表的选型,这里浅谈一下过程。

分库分表很可能会引入某一种中间件,因为仅仅将数据库分开还不行。HA,FailOver等特性,是同时需要的。

分库分为垂直分和水平分。垂直面向的是业务拆分,即将一部分表按照业务逻辑独立到其他库中;水平面向的是容量,即通过分库分表的模式使数据有一个扩张的途径。

数据一定要有一个可以度量的切分维度,否则就过于分散,或者过于倾斜,影响后续的处理。

数据同步

有分就有合,比如某些报表业务需要全量的数据。

不同业务通过共享数据库来共享数据不得不说是个非常蠢的主意。这个时候就需要一些数据同步工具。

数据同步组件可以说是一个公司的必备组件。有基于最后更新时间的高延迟同步工具,也有基于binlog的低延迟同步工具。有的公司为了稳定,还会有所谓的多机房同步。

数据同步最怕异常,因为大多数同步都有顺序性要求。一切运行良好的时候,大家皆大欢喜;一旦出现异常,就需要其他手段来保证异常期间的数据同步和延迟。

这都是些脏活,自动化有时候会适得其反,监控是第一位的。

分层的数据存储

可以预见的是,即使你分库分表了,还是能很快达到瓶颈。分库分表后,你的一些统计功能可能还用不了了,在一些传统的管理系统上,这是硬伤。

一个分层的数据存储层是必要的。你的一些业务,可能一个分支走的是MySQL,换了另外一个条件就成了ES。

不同的DB做不同的事情。RDBMS只做原是数据的存储和查询,是扁平快的数据通道;特定的单机高性能DB,做一些汇聚和科学计算;分布式的类RT的存储,用来存储一些中等规模的数据,并提供一些中延迟的搜索功能;海量的存储系统,存储系统所有的历史记录,并提供离线分析功能。

不要想着某一类存储解决所有的问题,那是骗人的。存储部分的复杂性不是普通的微服务能够相比的。

是谁保证了分层的数据存储设计呢?除了一部分通过MQ分发数据的业务,还是得靠我们的数据同步组件。

缓存

但DB的压力实在是太大了,我们不得不考虑缓存。缓存不能乱用,有两个原则:一个是缓存不能侵入业务,也就是不能带有业务逻辑;一个是缓存的命中率要高,否则适得其反。缓存是对高并发、高速接口的补充,是系统稳定性的必要不充分条件。

除了Redis等外置的缓存集群,jvm内缓存也是一个比较重要的场所。缓存的存在是因为I/O设备的缓慢,通常放在内存中,断电后即消失。

缓存涉及到源数据库和缓存数据库之间的数据同步。通常,更新源库时,会同时删掉缓存中相关的就数据,这样在下次读取的时候,能够读取到最新的数据。

缓存限制最大的就是其容量问题,而且都贵的很。假如业务模式固定,一些kv存储使用LevelDB或者HBase等方案,会显著节约成本。

模块化

是时候将工程模块化了,毕竟上百个程序员共享一个代码库,风险已经很大了。

模块化通常会按照业务线进行拆分。比如,支付模块和报表模块的拆分。

模块拆分后,相似的模块会共享数据库。但更多的是通过冗余数据来解决,这样能将业务解耦,一部分出现问题,另一部分能够运行良好。好比你隔壁出了杀人案你第二天还能正常去上班。

模块之间要找到一种交互方式,比如使用HttpClient、OkHttp等。重要的是统一,统一了以后就有一个高大上的名字了:RPC。

一个小模块很有可能会发展为一个大的业务线,也有可能无人问津。

MQ

模块化之间另一种共享数据或者数据交互的方式就是MQ。除了有削峰等功效,MQ更多改变的是一种交互模式,一种对业务的解耦。

Kafka几乎每个公司都在用,最高能有几十万的吞吐量。RabbitMQ、RocketMQ等,更多用在可靠性要求非常高的场景,但比较耗机器。

MQ资源一般都要求绝对的高可靠,作为基础设施,一旦出问题,将带来非常大的事故。设计的时候要考虑异常情况下的数据处理流向,以及MQ恢复后的补偿策略。

MQ集群设计的比较小一些才合理,避免不同业务,不同可靠性级别的消息互相影响。MQ在业务上和功能上要相互隔离,做到最小服务集合。

为了避免MQ当机对正常业务产生影响,非重要链路上的MQ不能阻塞业务的正常进行,这种消息通常通过异步线程发送。

微服务

我们已经使用消息和模块化,将系统拆分成了多个工程。将这些工程使用统一的方式管理起来,统一其交互模式和在上面的治理,就是微服务的范畴。

微服务就是一个多模块项目规范化的过程。非规范的服务与微服务体系,是要共存一段时间的,如何保证新旧服务的替换,是一个管理上的问题。

功能组件

根据SpringCloud的描述,一个服务想要被发现,需要将自己注册到通用的注册中心,其他服务可以从同一个地方,获取它的实例,进而调用。

而真正产生调用的功能,就是RPC的功能。RPC要考虑一系列比如超时、重拾、熔断等功能。在某些访问量非常大的节点,可能还要考虑预热。

RPC要能产生一些统计性数据,比如TPS、QPS、TP值等,很显然SpringCloud是缺乏的,我们要借助外部系统进行分析。

在外部请求流转到内部之前,需要经过一层网关的处理。像一些通用的操作,比如权限、限流、灰度等,就可以在网关层处理。

服务治理

微服务最重要的特色就是其治理功能。服务治理的依据就是监控信息。通过统计每次调用的大小、耗时、分布,能够得出服务的大体拓扑。

通常以下信息最有用: 1、QPS,时间序列的qps分布,最高区间qps 2、平均响应时间,接口的平均响应时间,最大耗时和最小耗时 3、TP值分布,90%,99%等请求是在x耗时内完成

通过以上信息能够对服务进行画像。是扩容、缩容、专项治理的数据依据。

微服务引出的另外一个问题就是调用链,即某个请求的真实路径。分布式环境下的问题排查,会非常的困难,调用链能够帮助研发快速定位问题,并帮助理解业务的数据流向。

服务治理的目的就是找到不合理的请求和分布,比如某个接口耗时太长;某个接口请求量大,需要加缓存;某个功能依赖链条过长,需要业务优化等。

服务治理要借助大量的外部分析工具,更多通用的业务模型,需要大数据平台的支持。

我们把监控/报警也放在服务治理的部分,在《这么多监控组件,总有一款适合你》中,我们详细的讨论了监控部分的技术选择方案。

日志

微服务产生的另外一个问题就是日志太过分散。一个核心的业务可能有上百个实例,你不可能打开100个终端去看日志。这就涉及到日志的收集。

日志归集功能就是把分散的日志集合到一个地方,它的主要挑战就是数据量。

通常日志分为两部分,一部分是全量的,可以通过定时同步等方式,备份到日志堡垒机或者hdfs中;一部分是过滤后的日志,比如一些异常信息,集中在某一个处理平台中进行报警。

很多研发喜欢将用户行为数据输出到日志文件中,这部分日志被收集后,会通过流计算或者离线计算,得到一些推荐和模型。日志信息进入了大数据处理的范畴,我们不过多描述。

持续集成

如果一个上点规模的公司,技术团队有什么值得一做的系统,那么发布系统算一个。《发布系统有那么难么?》中,谈了一种可能的模式。

发布系统就是给一堆脚本包了一张方便的皮。一些流程性工具、发布验证、CI/CD功能,很容易能够添加到自己的发布系统中。

很多微服务推广的文章中,谈到虚拟化(Docker)等,其实不是必须的。虚拟化减少了服务编排的时间,能够方便的进行扩容和缩容,但对监控、日志收集、网络拓扑等,要求比较高。建议是整个体系中的最后一步而不是第一步。

你的系统是否灵活,还与公司的文化环境相关。如果上个线走审批流程就需要一两周,那么做一个敏捷的持续集成系统就不是那么必要了。

基础设施

基础设施更多指的是运维体系,这是支撑整个系统健康发展的基石。我倾向于基础运维和基础架构不分家,因为它们的模式和文化,是一个公司研发环境的基石。

另外一些基础组件,比如配置中心、调度中心、分布式锁管理等,都对可靠性有较高的要求。

END

这套体系看着简单,也有固定的解决方案。但问题就在于,许多公司从成立玩到倒闭,玩了那么多年,还是没玩好。

真是可怜。

关注下面的标签,发现更多相似文章
评论