图15
拆分后的帐号主体库，是最核心业务库。库里围绕帐号四要素（用户名、密码、邮箱、手机号）组织数据，这样帐号的核心流程登录、注册的数据依赖就不再受其他数据的干扰。这种拆分方式属于垂直拆分，将表根据一定的规则划入不同的库。
（3）数据迁移实践
分库分表方案实施中代价最大的是数据迁移，帐号系统在垂直分库实践中主要利用mysql的主从复制机制来降低数据迁移的成本。先让DBA在原有主库上挂新的从库，将表数据复制到新库中。为保证数据一致性，线上切库时分三步处理（图16）。
- step1：禁写主库，确保主从数据同步一致 ；
- step2：断开主从，新库成为独立主库；
- step3：应用完成新库路由切换（开关实现）。
图16
这些操作在DBA的配合下，可以把对业务的影响控制在分钟级，影响相对可控。而且整个方案代码层面改造成本也非常小。唯一要注意的是一定要做上线前的演练。
除了上面垂直分库的场景外，帐号还经历过单个核心业务表数据量过亿后的水平拆分，这个场景复制迁移的方案就不适用。拆分是在18年底实施的，方案借助开源的Canal实现数据迁移。整体方案如下（图17）。
图17
四、监控治理
监控治理的目的，是让我们实时了解系统状况，及时进行故障的预警，并能辅助快速的问题定位。早期帐号就经历过，告警内容不全面，研发不能及时收到告警。有时收到了告警，但因为原因指向不明，告警问题排查困难，处理时间过长等。随着持续治理，经过多次线上的验证，我们能做到问题感知灵敏，处理迅速。
4.1 监控内容
我们把监控的内容归纳为三个维度（图18），从上到下分别是：
- 上层的应用服务监控：监控应用层的状况，例如：服务访问的吞吐量、返回码（失败量）、响应时间、业务异常等；
- 中层独立组件监控：独立组件涵盖服务运行的中间件，例如：Redis（缓存）、MQ（消息）、MySQL（存储）、Tomcat（容器）、JVM 等；
- 底层系统资源监控：监控主机和底层资源，例如：CPU、内存、硬盘 I/O、网络吞吐等；
监控内容涵盖三层的原因，如果你只关注应用服务，如果问题发生，你只是知道了一个结果，无法进行快速定位分析，只能根据经验排查各项的可能性，这样的故障处理速度是没办法忍受的。而往往上层的应用的告警，可能就是一些组件或则底层系统资源的异常引起的。假设我们遇到服务响应时长告警时，如果这时候有对应JVM FGC 时长告警、或myql的慢查sql告警，这就很方便我们快速的明确优先排查的方向，确定后续的处理措施。
图18
组件监控、底层资源监控除了有支撑定位问题的作用外，另一个目的是可以提前排除隐患。很多隐患一开始对应用服务影响比较有限，但这种影响会随着调用量等外部因数变化慢慢放大。
监控内容的维护，三个维度的监控内容中，底层系统资源和中层独立组件，内容相对固定，不需要经常维护。而上层的应用服务监控中涉及业务异常的，就需要随着功能版本迭代，不停的做加减法。
4.2 关联指标聚合
三个维度监控的内容，因为公司内分工的存在，研发、应用运维、系统运维，容易出现各管各的，监控指标也可能会分散在不同系统，这样是非常不利于问题定位分析。最好的监控系统是能将这三个维度的指标进行打通，这样问题分析处理会更加高效。下面是我们在跟踪“偶发性dubbo服务线程满”问题时的经历。偶发性问题排查的难点，不能拿一次的分析结果定论。借助公司业务监控系统的帮助，我们排除了redis等中间组件的影响后，我们就开始将关注点放在了主机指标上，为了方便问题定位，我们自己做了 虚拟机反推 宿主物理 再到宿主机上所有虚拟机的关键指标（CPU、IO、NET)聚合，效果如下（图19）。经过多次验证后确定了宿主机上个别应用磁盘IO异常过高导致。
