我以淘宝的技术架构演变为例。 随着淘宝从一个大型系统项目演变为分布式架构，你可以清楚地理解为什么需要应用拆分。
1 人员视角。
维护一个假名项目的百万级代码怪物（虽然物理部署是分开的），从发布到上线，从人员角度来看，数百人同时在同一个项目上开发。 一旦线上出现问题，所有代码都需要，从人员角度来说，基本上是可以容忍到极点的。
2 商业视角
淘宝包含了太多的业务：用户、产品、交易、支付等，早期所有代码都在同一个项目中。 代码严重影响了业务效率。 每个企业都有自己的需求，需要部署自己的应用程序。 各自的发展需要。
3 从架构角度
从数据库侧集中式数据库架构的瓶颈问题以及连接池数量的限制（数据库提供约5000个连接）来看，数据库CPU已经达到了限制的90%。 数据库端也需要考虑垂直拆分。
4、迫切需要迈向大规模分布式时代，应用拆分是首要需求。
1）首先，工程代码垂直拆分
将整个项目代码垂直拆分为业务单元。
淘宝按照业务单位分为类似这样的系统：UM()、SM()……以及几十个工程代码。
2）应用服务拆分
将所有与呼叫相关的接口拆分为业务单元。
例如项目框架拆解流程，商店系统需要访问用户头像的界面。 用户头像界面独立部署在用户中心（UIC）的集群服务器上。 随着拆分的进行，淘宝的业务接口中心变成了：UIC（用户中心服务）、SIC（商店中心服务）等与业务部门部署的集群。
最终演变成下图，按照业务单元进行服务的拆分和部署，比如用户中心、产品中心等：
总之，系统拆分是单一程序向分布式系统演进的关键一步。 这也是非常重要的一步。 拆分的好坏直接关系到未来系统的可扩展性、可维护性和扩展性。 拆分工作并不难理解，但是如何正确拆分，什么方法和原则可以帮助我们拆分得到一个理想的系统：一个高可用、可扩展、可维护、可扩展的分布式系统。
下面主要从拆分要求、拆分原则和拆分步骤开始：
拆分要求
1、组织架构的变化：最初的团队逐渐壮大，分裂为多个团队。 团队根据不同的业务线进行划分。 为了减少各个业务系统和代码之间的关联和耦合，已经不可能由几个团队共同开发，在一个代码库中提交代码，必须对原有的系统进行拆分，以减少团队之间的干扰。
2、安全性：这里所说的安全性不是系统级的安全性，而是指代码或者结果的安全性。 特别是对于很多具有核心算法的系统，为了防止代码泄露，需要对相关系统进行模块化和拆分。 隔离核心功能，保护知识产权。
3、可替代性：为了提供差异化的服务，有些产品需要可定制的功能，可以根据用户的选择自由组合成完整的系统。 比如有些模块，免费用户使用的功能和付费用户使用的功能必须是相同的。 不同的是，这需要这些模块是可替换的，并且决定免费用户还是付费用户使用不同的模块来组装，这也需要系统的模块化拆分。
4、交付速度：单个程序最大的问题是系统复杂，影响整个系统。 也许一个小小的改动就会导致很多功能无法正常工作，从而大大降低了软件交付速度，因为每一次改动都需要进行大量的回归测试，才能保证每个模块都能正常工作。 因为我们不知道改变会影响什么，所以需要做很多重复的工作，这增加了测试的成本。 这时就需要对系统进行拆分，明确各个功能之间的关系，解耦。
五、技术要求：
1）由于技术栈固定，单体程序，尤其是比较大的系统，无法轻易进行技术升级，或者对新技术或框架的引入封闭； 每种语言都有自己的特点，单体程序无法享受其他语言带来的便利； 对应于团队，团队技术相对单一。
2）与基于业务的垂直拆分相比，基于技术的水平拆分也非常重要。 使用数据访问层可以隐藏对数据库的直接访问、减少数据库连接数量、提高数据使用效率等； 水平拆分点可以大大提高各个层级模块的复用性。
6、业务需求：由于一些特殊的业务需求，比如某个功能或模块的高可用、高性能、可扩展性等，虽然单体也可以整体部署在分布式环境中实现高可用，高性能等，但从系统维护的角度来看，每次变更都必须重新部署所有节点，这显然会增加很多潜在的风险和不确定性，所以有时不得不选择使用那些有特殊要求的。 从系统中提取功能并独立部署和扩展。
如何拆分 1. 拆分原理 2. 分布式应用拆分实战实践
以下是代码拆分过程中的实践经验：
1).设计骨架
骨架的设计是基础，影响最终的分裂结果，是成功分裂的指南。 按照技术、业务、部署打包、测试等维度进行规划设计。 以下是参考。
最终骨架模型级别：
根网络应用程序
//war，打包为单个war，整体部署
micro- //微服务pom
用户-
–
命令-
其他-
API-
biz //业务相关
//所有实体类
biz-base //一些无法拆分的代码有依赖的服务
biz-user //用户业务
biz- //客户业务
biz-order //订单业务
……
async- //一个框架
utils //工具类
2).分体技术
第一步，将整个项目根据业务和功能拆分为Maven模块。
首先是将技术方面分开。 我觉得这应该是分开他们最好的方式了。 将相关的类重构到一个包中，然后将其中一个单独出来。
3).分割
很多业务代码共享类，通常没有办法将类分门别类。 最简单的就是把所有的类合而为一，原则就是谁需要就看谁。 类没有太多的jar依赖和业务依赖，不会形成污染源。
4）公共业务
同和方法不再重复，也被各商家所依赖。 这些业务大部分都是过渡性的项目框架拆解流程，在未来的迭代演进过程中可以通过其他方式进行抽象和整合。
5）业务代码拆分
拆分企业是最痛苦的事情。 这取决于原始代码的整洁程度和相互依赖的程度。 一般采用以下两种方法之一：
选择哪种方法可以根据代码的整洁程度和相互依赖的程度而定。 如果代码干净且相互依赖较弱，则可以采用前者，否则可以采用后者。
6）拆分微服务
有了上述分离的基础，每个微服务就可以在适当的业务迭代时迁移到不同的代码仓库，完成进一步的隔离管理。
微服务架构框架
业界开源的微服务架构框架为微服务提供了关键思想，例如Dubbo和Cloud（请关注后续文章，我会详细解释它们的区别、优缺点）
Dubbo是一个开源的分布式服务框架。 其最大的特点是分层结构。 使用这种方法，每一层都可以解耦（或最大限度地松散耦合）。
云是一个微服务框架。 与Dubbo等RPC框架相比，Cloud提供了一整套分布式系统解决方案。
微服务架构是互联网技术发展的必然结果。 它主张将单个应用程序划分为一组小型服务。 各项服务相互协调配合，为用户提供最终价值。
分布式架构应用拆分总结：
1.明确分拆原则和要求。
2、梳理业务模块之间的依赖关系。
3、按照业务单元，实体和应用项目进行拆分，分别部署。
4、按照业务单元拆分应用服务，避免循环依赖和双向依赖。
5. 提取公共接口、实体和服务，并将其单独部署为公共服务。
