微服务的缺点：
微服务解决的是计算节点的问题，然而根源却在存储节点。当业务量越来越庞大，存储编码和管理都会面临新的问题。
数据库：
假设你的业务增长的很好。项目开始，你的sql玩的越6，那么给后人埋的坑越多。因为sql的功能太丰富了，一不小心你，就炫技了。你会发现，林子越大。对sql的规范要求越高。一些官宣的特性，在公司内是严格禁止的。
市场发展很好，终于报应来了。以前的技巧变成了现在的累赘。慢查询、全文扫描，招招毙命。想要加缓存，结果发现无从下手；想要分库分表，结果发现无从下手；想要分库分表，结果关系错综复杂。
小表和宽表：
一个超过3个表的联合查询，大概率是不合理的。加缓存和分库分表之前还是得重新设计一下数据表。
小表提供了最基本的数据。一些联合查询，是直接可以在程序里进行循环拼接的。程序里循环1000次10毫秒的查询，比单次查询耗费6秒要强的多。这就是分布式系统的特点，小耗时的批量查询。
宽表通过冗余的方式，提供了某个重要功能常用的分析数据。这种表的字段一般都特别多。在写入时通过拼接获取冗余数据，一般用在读多写少的场景。
分库分表：
分库分表很可能会引入某一种中间件。分库分为垂直分和水平分。垂直面向的是业务拆分，即将一部分表按照业务逻辑独立到其他库中；水平面向的是容量，即通过分库分表的模式使数据有一个扩张的途径。
数据一定要有一个可以度量的切分维度，否则就过于分散，或者过于倾斜，影响后续的处理。
数据同步：
某些报表业务需要全量的数据。不同业务通过共享数据库来共享数据，是一个非常不好的主意。这个时候需要一些数据同步工具。
数据同步最怕异常，因为大多数同步都有顺序性要求。一旦出现异常，就需要其他手段来保证异常期间的数据同步和延迟。这都是脏活，自动化有时候会适得其反，监控是第一位的。
分层的数据存储：
即使你分库分表了，还是能很快达到瓶颈。分库分表后，你的一些统计功能可能还用不了了。在一些传统的管理系统上，这是硬伤。
一个分层的数据存储层是必要的。你的一些业务，可能一个分支走的是Mysql，另外一个条件就成了ES。
不同的DB做不同的事情。不要想着某一类存储解决所有的问题，那是骗人的。存储部分的负责性不是普通的微服务能够相比的。
是谁保证了分层的数据存储设计呢？除了一部分通过MQ分发数据的业务，还是得靠我们的数据同步组件。
缓存：
DB 的压力太大，我们不得不考虑缓存，缓存不能乱用，有两个原则：一个是缓存不能侵入业务，也就是不能带有业务逻辑；一个是缓存的命中率要高，否则适得其反。缓存是对高并发、高速接口的补充，是系统稳定性的必要不充分条件。
缓存涉及到源数据库和缓存数据库之间的数据同步。一般，更新源数据库时候，会同时删除缓存中的数据，这样就可以保证下次读取的是最新的数据。
模块化：
数百程序员共享一个代码库，管理难度和风险会很大。
模块化通常会按照业务进行拆分。比如支付模块和认证模块。 模块拆分后，相似模块会共享数据库，但更多的是通过冗余数据来解决，这样能将业务解耦。一部分出现问题，另一部分能够运行良好。
MQ:
模块化之间另一种共享数据或者数据交互的方式就是MQ。除了有削峰等功效，MQ更多改变的是一种交互模式，一种对业务的解耦。
kafka几乎每个公司都在用，最高能有几十万的吞吐量。RabbitMQ、RocketMQ等，更多用在可靠性要求非常高的场景，但比较耗机器。
MQ资源一般都要求绝对的高可靠，作为基础设施，一旦出现问题，将带来非常大的事故。设计的时候要考虑异常情况下的数据处理流向。以及MQ恢复后的补偿策略。
MQ集群设计比较小一些才合理，避免不同业务，不同可靠性级别的消息互相影响。MQ在业务上和功能上要相互隔离，做到最小服务集合。
为了避免MQ宕机对正常业务产生影响，非重要链路上的MQ不能阻塞业务的正常进行各种消息通常通过异步线程发送。
微服务：
已经使用消息和模块化，将系统拆分成多个工程，将这些工程使用统一的方式管理起来，统一交互模式和在上面的治理，这就是微服务的范畴。
微服务就是一个多模块项目规范化的过程。非规范的服务与微服务体系，是要共存一段时间的，如何保证新旧服务的替换，是一个管理上的问题。
功能组件：
根据spring cloud 的描述，一个服务想要被发现，需要将自己注册到通用的注册中心，其他服务可以从一个地方，获取他的实例，进而调用。
而真正产生调用的功能，就是RPC的功能。RPC要考虑一系列比如超时、重拾、熔断等功能。在某些访问量非常大的节点，可能还要考虑预热。
RPC要产生一些统计性数据，比如TPS、QPS、TP值等，很显然spring cloud 是缺乏的。我们要借助外部系统进行分析。
在外部请求流转到内部之前，需要经过一层网关的处理。像一些通用的操作，比如限流、权限、灰度等，就可以在网关层处理。
服务治理：
微服务最重要的特色就是治理功能。微服务治理的依据就是监控信息。通过统计每次调用的大小、耗时、分布，能够得出服务的大体拓扑。
通常以下信息最有用： 1、QPS，时间序列的qps分布，最高区间qps 2、平均响应时间，接口的平均响应时间，最大耗时和最小耗时。3、TP值分布，90%，99%等请求是在x耗时内完成。
通过以上信息能够对服务进行画像。是扩容、缩容、专项治理的数据依据。
微服务引出的另一个问题就是调用链，即某个请求的真实路径。分布式环境下的问题排查，会非常的困难，调用链能帮助研发快速定位问题，并帮助理解业务的数据流向。
微服务治理的目的就是找到不合理的请求和分布，比如某个接口耗时太长；某个接口请求量大，需要加缓存；某个功能依赖链条过长，需要业务优化等。 服务治理要借助大量的外部分析工具，更多通用的业务模型。需要大数据平台的支持。
持续集成：
发布系统就是给一堆脚本包了一张方便的皮。一些流程行工具、发布验证、CI/DI功能，很容易添加到自己的发布系统中。
很多微服务推广的文章中，谈到虚拟化（Docker）等、其实不是必须的，虚拟化减少了服务编排的时间，能够方便的进行扩容和缩容，但对监控、日志收集、网络拓扑等，要求比较高，建议是整个体系中的最后一步而不是第一步。
