官术网_书友最值得收藏!

Integrating monolithic

Whenever a choice is made to move away from the monolithic architecture in favor of the microservice-styled architecture, the time and cost axis of the initiative will pose some resistance. A business evaluation might rule against moving some parts of the monolithic application that do not make a business case for the transition.

It would have been a different scenario if we were developing the application from the beginning. However, this is also the power of microservices, in my opinion. A correct evaluation of the entire monolithic architecture can safely identify the monolithic parts to be ported later.

However, to ensure that these isolated parts do not cause a problem to other microservices in future, we must take one safeguard against the risk.

The goal for these parts of the monolithic application is to make them communicate in the same way as that of other microservices. Doing this involves various patterns and you utilize the technology stack in which the monolithic application was developed.

If you use the event-driven pattern, make sure that the monolithic application can publish and consume events, including a detailed modification of the source code to make these actions possible. This process can also be performed by creating an event proxy that publishes and consumes events. The event proxy can then translate these events to the monolithic application in order to keep the changes in the source code to a minimum. Ultimately, the database would remain the same.

If you plan to use the API gateway pattern, be sure that your gateway is able to communicate with the monolithic application. To achieve this, one option is to modify the source code of the application to expose RESTful services that can be consumed easily by the gateway. This can also be achieved by the creation of a separate microservice to expose the monolithic application procedures as REST services. The creation of a separate microservice avoids big changes in the source code. However, it demands the maintenance and deployment of a new component.

主站蜘蛛池模板: 宕昌县| 昌邑市| 鞍山市| 吴旗县| 和平区| 根河市| 璧山县| 郓城县| 安陆市| 穆棱市| 古交市| 珠海市| 铁岭县| 高雄县| 修水县| 玛纳斯县| 怀远县| 林口县| 丰城市| 资溪县| 汶上县| 德令哈市| 新竹市| 土默特右旗| 中方县| 巴南区| 华坪县| 永善县| 新田县| 毕节市| 大庆市| 陆河县| 宁城县| 汤阴县| 郑州市| 镇沅| 武陟县| 华蓥市| 蚌埠市| 城市| 正阳县|