从我接手的一个项目说起。先从一张微不足道的图来刷新一下思路：随着项目的快速迭代，项目代码变得臃肿，数据表接近百张。一些模块代码消耗了大量的CPU和内存。十几个开发者同时在同一个项目中开发十几个特性。多个模块、多个特性代码变更重叠，给测试、夹板和发布带来极大的考量，降低了发布效率。2.部署无弹性，可扩展性差。有些模块需要消耗大量的CPU和内存，有些模块需要支持高并发，有些模块需要的服务器资源很少。由于都在一个系统中，每个模块共享同一套服务器资源分布不均衡，无法针对具体业务进行合理分配和扩展。3、系统业务复杂，项目接手难度大。在一个系统中，它涵盖了大量的业务。一个新同事，三个月不一定能熟悉所有的模块。模块之间的各种耦合更是让人心酸；不敢轻易调整代码，修改一个问题很容易导致另一个问题。4、技术升级困难。同一个项目，技术架构单一，引入一个新技术会影响到所有模块。调整难度极大，增加了技术升级的风险。整体技术处于保守状态，难以升级适应快速发展。互联网技术的发展。为此，基于服务的拆分被提上了议事日程。喵～服务式拆分流程，只有在了解系统所有业务和数据库的前提下，才能进行拆分。由于系统长期上线运行，参与系统迁移的同事在不断迭代几个需求和跟进上线问题后，在了解业务的前提下进行了服务拆除工作整个系统。先理清各个模块的数据模型，然后确定各个模块的职责，这样就可以理清各个服务的边界了。1.旧系统外部关联解耦实际业务场景和系统交互极其复杂。这里我简化成如下模型来说明：根据确定的服务职责和边界，新建一个服务程序和数据库，并在新的服务接口B和C中约定将旧系统中的所有外部依赖A转移到新系统中系统，新系统通过写入的路由器将请求路由到旧系统。之所以把外部系统的解耦放在首位，是因为外部系统的对接需要协调相应的项目组配合整改，周期不可控。需要先完成线路不可控的部分，以便后续系统的内部模块可以快速实现。拆机上线。2.解耦旧系统模块之间的关系，将旧系统模块之间直接调用A，升级为rpc或http调用B，对外暴露接口，打断业务层或数据层之间的直接调用原始模块；原有系统数据库sql关联查询需要按模块拆解，避免跨模块表关联操作；3.程序向新系统的迁移将相关程序按模块迁移到新系统。在解耦旧系统模块和程序迁移的关系时，需要对旧系统业务有深刻的把握，清楚数据库中所有表和字段的作用，才能快速迁移。4.旧系统数据全量迁移旧系统中的所有数据通过脚本直接迁移到对应的新数据库中。至此，所有业务数据的写入和读取都是基于新服务的数据库，老系统已经迁移到新系统。关于服务拆除的灰度上线，根据系统的业务，制定相应的灰度上线策略。因为我们系统的整个业务都是围绕产品展开的。因此在灰度发布（金丝雀部署①）时，可以发布灰度测试产品，将白名单用户流量发送到新版本的服务器组进行验证。确认没有问题后，将逐步向所有用户开放。在验证期间，如果旧版本需要继续流入业务数据，则需要将产生的新的和变更的业务数据再次增量迁移到新数据库中。这样会增加增量数据迁移的工作量，容易出错。在升级过程中，我们停止了老版本系统中业务数据的存储：灰度测试用户产生的数据只存在于新数据库中。如何拆分一个快速迭代的系统一般互联网企业版的迭代速度都比较快，所以系统迁移的速度一定要快。如果周期太长，一个大的需求下来，系统变更就完全认不出来了，系统迁移相关的工作又得从头再来。为了尽快推动系统拆分，总结以上流程，我们需要考虑以下五个步骤：首先处理需要外部项目组配合的事项：新建服务，进行依赖迁移（外部系统接口依赖迁移，外部消息依赖迁移）；接口系统中的模块间依赖关系，定义服务的职责和边界；快速将模块迁移到新服务，同时进行数据迁移，进入灰度测试环境；灰度测试验证通过后，将增量数据迁移到新数据库，所有用户迁移到新系统；待上线稳定后，旧系统下线，回收相关运维资源。迁移后，我们需要继续改进东西跟上面向服务的技术支撑：服务拆分后，系统的运维需要补充额外的成本，维护和测试难度大呈几何级数增长。我们必须有相应的配套技术：自动化测试、持续集成、自动部署、配置中心、任务中心、日志监控等；分布式一致性事务问题：为了解决这类问题，我们可以通过业务补偿、可靠事件模型、TCC模型来开发。系统迁移工作带来的后续工作启示即使没有服务化拆分，也必须明确系统间各模块的职责边界，梳理业务模型，低耦合必须保证模块之间，以及模块的高内聚性；避免过多的数据表关联查询，以数据库作为存储数据的媒介，将业务逻辑转移到程序中去实现，也为后续的分库分表、面向服务拆分做准备；提前准备面向服务的支撑技术，大家关注底层平台。强大的底层平台支持帮助我们填补了前人踩过的坑：灰度发布、服务升级回滚、服务注册发现、断路器降级、自动部署等；服务后，尽可能尝试边缘业务的新技术，积累相关的迁移、服务、运维问题，构建一套比较完整的解决方案。完成一套完整的技术规范后，提升为核心业务，有利于新技术的传播；作者：彭占轩，来自金蝶Notes后端开发工程师，目前在做项目管理相关工作，逐步改造架构，在面向服务、分布式交易、p2p金融系统设计、互联网信息系统等方面有相关经验其他领域。【本文来自专栏作者张凯涛微信公众号（凯涛的博客）公众号id：kaitao-1234567】点此查看作者更多好文
