微服务不是所有，只是特定领域的子集

你们都在学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是缺少的，咱们要借助外部系统进行分析。

在外部请求流转到内部以前，须要通过一层网关的处理。像一些通用的操做，好比权限、限流、灰度等，就能够在网关层处理。

服务治理

微服务最重要的特点就是其治理功能。服务治理的依据就是监控信息。经过统计每次调用的大小、耗时、分布，可以得出服务的大致拓扑。

一般如下信息最有用：
一、QPS，时间序列的qps分布，最高区间qps
二、平均响应时间，接口的平均响应时间，最大耗时和最小耗时
三、TP值分布，90%，99%等请求是在x耗时内完成

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

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

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

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

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

日志

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

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

一般日志分为两部分，一部分是全量的，能够经过定时同步等方式，备份到日志堡垒机或者hdfs中；一部分是过滤后的日志，好比一些异常信息，集中在某一个处理平台中进行报警。

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

持续集成

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

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

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

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

基础设施

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

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

END

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

真是可怜。