更多精彩文章。

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

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

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

《使用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

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

真是可怜。