为了提升交付速度，获得持续交付能力，系统架构在设计时应该考虑如下因素：
- 为测试而设计：如果我们每次写好代码以后，需要花费很大的精力，做很多的准备工作才能对它进行测试的话，那么从写好代码到完成质量验证就需要很长周期，当然无法快速发布。
- 为部署而设计：如果我们开发完新功能，当部署发布时，需要花费很长时间准备，甚至需要停机才能部署，当然就无法快速发布。
- 为监控而设计：如果我们的功能上线以后，无法对其进行监控，出了问题只能通过用户反馈才发现。那么，持续交付的收益就会大幅降低了。
- 为扩展而设计：这里的扩展性指两个方面，一是支持团队成员规模的扩展，二是支持系统自身的扩展。
- 为失效而设计：俗语说：“常在河边走，哪能不湿鞋。”快速地部署发布总会遇到问题。因此，在开发软件功能之前，就应该考虑的一个问题是：一旦部署或发布失败，如何优雅且快速地处理。
系统拆分原则
大系统应该由很多组件（component）或服务（service）组成。组件通常在编译构建或者部署时被集成在一起，而服务可以由多个组件构成，能够独立启动运行，并在运行时与整个系统进行通信，成为整个系统的一个组成部分。
在系统拆分的同时，我们必须同时建立相应的构建、测试与部署和监测机制，而且，这些机制的建立与系统拆分工作同等重要。只有这样，才能既获得系统拆分的益处，又能管理因拆分带来的复杂性。
常见架构模式
- 微核架构，适合于客户端软件；
- 微服务架构，适合于大型后台服务端系统；
- 巨石应用，适合于创业公司或中小型项目；
架构改造实施模式
- 拆迁者模式，就是一次性重写所有代码；
- 绞杀者模式，就是不改变或少改变原有遗留系统，通过增加新的服务来不断替代遗留系统的功能；
- 修缮者模式，就是通过迭代，对原有遗留系统进行逐步改造，同时开发新的功能；
为了能够持续交付，并且降低架构改造的风险，建议团队根据实际情况，采用 绞杀者模式 或 修缮者模式 进行遗留系统的架构改造。
数据库的拆分方法
- 详细了解数据库结构，包括外键约束、共享的可变数据以及事务性边界等；
- 先拆分数据库；
- 数据库双写无误后，找到程序架构中的缝隙；
- 将拆分出来的程序模块和数据库组合在一起，形成微服务；
了解更多：https://t.zsxq.com/06R7mqJAq
