上下文

一个单片应用程序被创建为一个单一的逻辑可执行单元，通常由三部分组成：数据库、客户端用户界面和服务器端应用程序。任何更改/更新都意味着开发人员必须构建和部署服务器端应用程序的新版本/版本，其中包含特定于域的逻辑。

另一方面，微服务提供了一个面向业务的API，该API封装了代码业务功能。同一服务可以跨多个业务渠道和多个数字接触点在多个业务上下文中重用。它基于松散耦合的原则。

传统的软件开发方法（瀑布式、敏捷等）通常会产生单片部署产品。但在观看了SAP的转型历程之后，我们都意识到了这种传统方法的各种潜在问题——有限的重用、有限的可扩展性、有限的操作灵活性等）。

随着HANA云与YaaS微服务生态系统的结合，我们正朝着创建产品而不是项目的方向发展。但是现有的遗留系统呢？下一步是将遗留应用程序重新设计为微服务吗？如果是的话，那么未来的道路是什么？

应用现代化显然有两种方式——大爆炸重写和扼杀新概念。在BigBangRewrite中，我们将集中精力从头开始将整个应用程序重写为基于微服务的应用程序。这是非常危险的，而且在遗留应用程序中总是隐藏着一些功能和业务上下文，人们已经忘记了，返利折扣，可能会错过这些功能和业务上下文。

另一方面，扼杀的目的是逐步淘汰一件事，换成更好的事，廉价且可扩展。

扼杀者应用

概念是围绕旧系统的边缘逐渐创建一个新系统，并让它缓慢增长，直到旧系统被扼杀。这种模式考虑了一个事实，即企业从来没有真正生活在一个绿地世界。扼杀模式帮助我们分阶段管理单片应用程序的重构。

扼杀有3个步骤：

这种方法最好的地方是它比一次大迁移更快、更安全地创造增量价值。它还有增量方法，消费返现，商城返利系统，这意味着如果在任何时候，您看到新创建的微服务出现故障，您可以改变方向。从遗留系统中最不复杂的模块开始，将遗留系统中的现有模块转换为独立的微服务。每次转换模块时，整体都会收缩/扭曲。一旦重构了足够多的模块，这个整体要么就完全消失了，要么就小到足以成为另一个服务。粘合代码或反损坏层在转换过程中非常重要，它可以防止新服务被遗留应用程序的概念损坏。在开发阶段，它形成了整体和微服务之间的集成层。

总是拆分重构：

随着时间的推移，微服务的数量会增长，您的开发团队的敏捷性和速度将会提高。

使用strangler模式

在单片应用程序中使用这种重构模式的先决条件是：

strangler模式不应一次应用一页–业务流程模块的创建非常重要。最小的层次是单个独立的微服务。

这种新的和即将出现的开发方法尚未被大多数软件公司完全采用。但是，产业云，在这一领域有很多电子商务公司的参考资料，他们采用这种模式，大数据行业前景，转向Netflix、Amazon等微服务

在对旧应用程序进行现代化或设计新应用程序时，需要考虑的一个重要方面——设计成在未来很容易扼杀——模块化、分层，使其可扩展。毕竟，我们今天正在编写明天的遗留软件。所以让我们让它在明天优雅地消失吧！

参考文献

https://www.martinfowler.com/bliki/StranglerApplication.html

https://www.ibm.com/blogs/bluemix/2017/07/using-microservice-application-patterns/

https://www.nginx.com/blog/refactoring-a-monolith-into-microservices/

https://paulhammant.com/2013/07/14/legacy-application-stranglation-case-studies/

https://www.michielrook.nl/2016/11/勒死模式练习/