“大系统小做”原则：
持续交付架构要求：系统架构在设计时应该考虑如下因素
1.为测试而设计
2.为部署而设计
3.为监控而设计
4.为扩展而设计：支持团队成员规模的扩展，支持系统自身的扩展
5.为失效而设计：一旦部署或发布失败，如何优雅且快速的处理
系统拆分原则：
1.作为系统的一部分，每个组件或服务有清晰的业务职责，可以被独立修改，甚至被另一种实现方案所替代
2.“高内聚，低耦合”，使整个系统易于维护，每个组件或服务只知道尽可能少的信息，完成相对独立的单一功能
3.整个系统易于构建与测试。将系统拆分后，这些组件仍需要组合在一起，为用户提供服务
4.使团队成员之间的沟通协作更加顺畅
常见架构模式：
微核架构：又叫插件架构，指的是软件的核心框架相对较小，而其主要业务功能和业务逻辑都通过插件实现。核心框架部分通常只包含系统启动运行的基础功能，例如基础通信模块、基本渲染功能和界面整体框架等。插件则是相互独立的，插件之间的通信只通过核心框架进行，避免出现相互依赖的问题。
优点：
良好的功能延伸性：需要什么功能，开发一个插件即可
易发布：插件可以独立的加载和卸载，使它比较容易发布
易测试：功能之间是隔离的，可以对插件进行隔离测试
可定制性高：适应不同的开发需要
可以渐进式的开发：逐步增加功能
缺点：
扩展性差：内核通常是一个独立单元，不容易做成分布式，但对客户端软件来说，这就不是一个严重问题
开发难度相对较高，因为涉及插件和内核的通信，以及内部的插件登记机制等，比较复杂
高度依赖框架，既享受框架带来的方便性，当框架接口升级时又可能会影响所有插件，导致大量的改造工作
微服务架构：将单一应用程序划分成一组小的服务，服务之间相互协调，相互配合，为用户提供最终价值。
优点：
扩展性好：各个服务之间低耦合。可以对其中的个别服务单独扩容
易部署：每个服务都是可部署单元
易开发：每个组件都可以进行单独开发，单独部署，不间断的升级
易于单独测试：如果修改只涉及单一服务，那么只测试该服务即可
缺点：
由于强调互相独立和低耦合，服务可能会被拆分的很细。这导致系统依赖大量的微服务，变得很凌乱和笨重，网络通信消耗也会比较大
一次外部请求会涉及内部多个服务之间的通信，使得问题的调试与诊断比较困难，需要更强大的工具支持
为原子操作带来困难，例如需要事务类操作的场景
跨服务的组合业务场景的测试比较困难，通常需要同时部署和启动多个微服务
公共类库的升级管理比较难。在使用有一些公共的工具性质的类库时，需要在构建每个微服务时将其打包到部署包中
巨石应用：也称巨石架构，是指由单一结构体组成的软件应用，其用户接口和数据访问代码都绑定在同一语言平台的同一应用程序
优点：
利于开发和调试：当前所有开发工具和IDE都很好的支持了巨石应用程序的开发，系统架构简单，调试方便
部署操作本身比较简单：只需一个War文件即可包含所有功能
很容易扩展：只要在负载均衡器后面运行这个应用的多个副本就可以扩展应用程序。
缺点：
对整体程序不熟悉的人来说，容易产生混乱的代码，污染整个应用，给老代码的学习和理解带来困难
难与新技术共同应用
只能将整个应用作为一个整体进行扩展
持续部署比较困难。为了更新一个组件，必须重新部署整个应用程序
架构改造实施模式
拆迁者模式：根据当前的业务需求，对软件架构重新设计，并组织单独的团队，重新开发一个全新的版本，一次性完全替代原有的遗留系统
优点：与旧版本无瓜葛，没有历史包袱，可以按预期进行架构设计
缺点：
业务需求遗漏：软件的历史版本中，有很多不为人熟知的功能还在使用
市场环境变化：由于新版本架构无法 一蹴而就，当市场需求发生变化时，就会错失市场良机
人力资源消耗大：必须分出人力，一边维护旧版本的功能或紧急需求，一边要安排充分人力进行架构改造
闭门造车：新版本上线后，无法满足业务需求
绞杀者模式：保持原来的遗留系统不变，当需要开发新的功能时，重新开发一个服务，实现新的功能。通过不断的构建新的服务，逐步使遗留系统失效，并最终替代它
优点：
不会遗漏原有需求
可以稳定的提供价值，频繁的交付版本，可以让你更好的监控其改造进程
避免“闭门造车”现象
缺点：
架构改造的时间跨度会变大
产生一定的迭代成本
修缮者模式：将遗留系统的部分功能与其余部分隔离，以新的架构进行单独改善。在改善的同时，需要保证与其他部分仍能协同工作
优点：
系统外部无感知
不会遗漏原有需求
可以随时停下改造工作，响应高优先级的业务需求
避免“闭门造车”现象
缺点：
架构改造的时间跨度会变大
会有更多的额外的架构改造迭代成本
数据库的拆分方法：
详细了解数据库结构，包括外键约束、共享的可变数据以及事务性边界等
先拆分数据库
数据库双写无误后，找到程序架构中的缝隙
将拆分出来的程序模块和数据库组合在一起，形成微服务