微服务系统梳理维护
微服务系统需要定期梳理，以跟踪系统的变更和分析可能存在的瓶颈。
梳理系统服务属于系统维护与治理职责。
从大的方向统理出系统包含的功能，识别出哪些是核心功能（黄金功能）。
同时从小的方面梳理功能对应的流程以流程上包含的各个节点。每个节点要找出强依赖和弱依赖。
- 强依赖：少了则不能实现。需要准备灾备方案。例如，DB 挂了切换到 MQ。
- 弱依赖：不影响功能的使用。例如，日志记录。
按系统分类梳理
接口服务类系统
梳理出服务提供的所有接口，找出黄金接口，必须确保黄金接口可用不可降级，可使用 灾备方案 来实现。例如，异地双机房。
网页类系统
网页类首页、类目、导航栏、展示区等需要确保可用，这是脸面，一定不能 丢脸，每个区域对应的信息可以设计多级缓在瞎了眼，有托底数据，要保证页面上有内容。
任务类系统
要使用分布式任务系统，不可单点。可以使用开源方案：xxl-job，Elastic-Job，或利用 Zookeeper + 定时任务。
核心流程梳理
核心流程的梳理是要找出关键节点，找出强依赖节点，强依赖节点是关键节点，所依赖的资源需要确保可用。
要定期对系统进行梳理，确保没有遗漏，无论系统如何演进与变更，都能很好完成服务治理。
微服务库表拆分
将一个大而全的应用的数据库进行拆分，使各个微服务有自己独立的数据库。
拆分方案
RPC 调用
原先直接查库改为调微服务接口，一方微服务提供接口给另一方调用。
实现系统之间解耦。需要关注接口提供方宕机，或调用超时的发生。
需要有容错机制，比如熔断，降级等。要考虑好数据托底，比如本机缓存，多级缓存等。
数据异构
通过数据异构的方式实现两个系统之间的数据解耦，比例拆分后的 A 服务与 B服务原来是一张表，B服务用到表中的某几个字段，可以利用异构中间件把 A 服务的表按需异构到 B 服务的表中。例如，使用 MQ + canal 方案实现。
折库步骤
A 库，B 库（新搭建），C 库（新搭建）。注意：需要停止写的操作。
B，C库以从库的形式挂载到 A 库。
将主库 A 设置为只读模式。命令：
set global read_only=on。待从库无延迟后，从库 B，C库停止复制。命令：
stop slave。此时，A、B、C库均为只读模式。开发修改应用中连接数据库的 URL 指向对应的数据库（此时可回退），通知 DBA 将 A，B，C 三库打开读到（打开后不可回退）。命令：
set global read_only=off。折分完成，监控验证。
无误后，删除 A 库的冗余表。
主从结构在同步时是全量复制的。可以用
rename先标记，一段时间后执行drop掉。
回退方案：
- B、C库打开复制。命令：
start slave。 - A 库打开读写。命令：
set global read_only=on。
