微服务不是全部，只是特定领域的子集
大家都在学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
这套体系看着简单，也有固定的解决方案。但问题就在于，许多公司从成立玩到倒闭，玩了那么多年，还是没玩明白。
真是可怜。
正文到此结束
- 本文标签： 时间 生命 模型 QPS 虚拟化 事故 NOSQL 代码 锁 http 分布式系统 缓存 mysql sql 管理 开发 推广 rabbitmq JVM CDN HBase 大数据 快的 统计 高并发 注册中心 https HDFS redis 敏捷 src RocketMQ 配置中心 自动化 集群 Docker client 分布式 springcloud 并发 db 压力 数据 实例 企业 MQ 分布式锁 微服务 备份 线程 UI 程序员 同步 文章 本质 限流 spring 数据库 配置
- 版权声明： 本文为互联网转载文章，出处已在文章中说明(部分除外)。如果侵权，请联系本站长删除，谢谢。
- 本文海报： 生成海报一 生成海报二
热门推荐
相关文章
近期评论
-
你这基本没有更新呀，最近文章显示还是2019年的文章。不符合要求哈
-
关键词：慕云博客 链接：https://www.lilun.me 描述：分享原创文字的个人博客
-
-
-
可以提供一下源码吗
-
不是商业站，鸡娃学习笔记
-
-
-
-
听他们说很厉害的样子
Loading...
![[HBLOG]公众号](http://www.liuhaihua.cn/img/qrcode_gzh.jpg)
