概述
由阿里巴巴中台战略思想，共享平台开发部承载了多数企业中的公共抽象能力，其中用户中心承载了公司2b和2c的所有用户服务，后业务重新规划，导致需要把2c的用户 迁移到一个新服务里边，因此面临很多困难；
1 一部分的接口是c端独立的，理论上直接抽到新的服务里就可以了，但用户中心在集团中接入了太多应用，而且c端用户的流量由非常大，如果直接采用新的服务，难保不会发生问题
2 之前的用户中心采用了已中策略模式，根据appName来路由具体的对应执行类，如果今天直接抽走到新的服务，那么对应的上游业务都要改动，用户中心发展到今天，已经接入进了70几个应用，改动周期非常大，改动后的联调工作短期也难以承接；
dubbo负载均衡介绍
LoadBalance 中文意思为负载均衡，它的职责是将网络请求，或者其他形式的负载“均摊”到不同的机器上。避免集群中部分服务器压力过大，而另一些服务器比较空闲的情况。通过负载均衡，可以让每台服务器获取到适合自己处理能力的负载。在为高负载服务器分流的同时，还可以避免资源浪费，一举两得。负载均衡可分为软件负载均衡和硬件负载均衡。在我们日常开发中，一般很难接触到硬件负载均衡。但软件负载均衡还是可以接触到的，比如 Nginx。在 Dubbo 中，也有负载均衡的概念和相应的实现。Dubbo 需要对服务消费者的调用请求进行分配，避免少数服务提供者负载过大。服务提供者负载过大，会导致部分请求超时。因此将负载均衡到每个服务提供者上，是非常必要的。Dubbo 提供了4种负载均衡实现，分别是基于权重随机算法的 RandomLoadBalance、基于最少活跃调用数算法的 LeastActiveLoadBalance、基于 hash 一致性的 ConsistentHashLoadBalance，以及基于加权轮询算法的 RoundRobinLoadBalance。
架构设计及说明
针对问题1 ，上图是解决方案中最初始的状态，toc服务和原始服务公用redis，mysql,ons
本方案使用dubbo权重做流量控制，负载均衡策略使用dubbo缺省的加权随机；
原用户中心6台机器，每台机器权重配置100，新toc服务2台机器，每台机器权重配置25，那么toc服务占用toc总流量的50/650,也就是7%的流量，下次发布提升to服务的权重，每次发布前进行一次倍权操作，流量就会逐渐迁移到新的toc服务中；
之后遗留的问题还有redis拆分，数据库平滑迁移，消息队列迁移
且听下回分解
