单体架构在最初各方面效能、效率、开发、迭代的成果都比较好，不过随着单体越来越臃肿，各方面效能降低，这时候微服务的优势才得以体现。任何时候都是单体优先，只有单体结构变得越来越庞大，效能降低，并满足以下 4 个条件的时候才考虑进行微服务化：
l 要有快速迭代的能力。
l 要有基本的监控。
l 要有快速的集成。
l 要有一个Dev0ps文化。
图1单体架构和微服务架构生产力
上图单体架构和微服务架构在不同系统复杂度下不同的生产力，其中黑线指的是单体，灰线是微服务架构。表明复杂度和生产率拐点的存在，但并没有量化复杂度的拐点到底是多少，或者换种说法，系统或代码库的规模具体达到多大才适合开始进行微服务化的拆分。另外一个实施前提是基础设施的自动化，达到一定规模以后运维复杂度呈乘数级飙升，从开发之后的构建、测试、部署都需要一个高度自动化的环境来支撑，这样才能有效降低边际成本。因此，微服务化的原则是要渐进改革。
胶水代码也被称为容灾层，这是因为胶水代码保护微服务全新域模型免受传统单体应用域模型的污染。胶水代码在这两种模型间提供翻译功能。
为了解决单体式本身问题必须深入单体应用做出改变。下面我们来看看改变单体应用的策略。
（1）排序模块转成微服务
一个巨大的复杂单体应用由上百个模块构成，每个都是被抽取对象。决定抽取的标准至关重要。
（2）从哪里开始拆分接缝
从接缝处可以抽取相对独立的一部分代码，对这部分代码的修改不会影响系统的其他部分，这些接缝就可以作为服务的边界。
（3）如何抽取模块
抽取模块的第一步就是定义好模块和单体应用之间的粗粒度接口，由于单体应用需要微服务数据、因此这是一个双向 API。必须在负责依赖关系和细粒度接口模式之间做好平衡。
（4）杂乱依赖的根源数据库
在业务层的代码已经通过分层组织到相应的包中了，只有数据库是共用的，是一个巨大的 API。对于同一张表被多个限界上下文使用的场景，以下是一些处理的步骤和原则：
l 分清代码中对数据库进行读写的部分。
l 打破外键关系
l 共享静态数据
l 共享数据
l 共享表
l 实施拆分
总之，将现有应用迁移成微服务架构的现代化应用，应该通过逐步迁移的方式实现。在拆分的同时，需要同期配置服务治理平台，完成服务发现、配置管理、日志管理、监控等内容。
