my understanding is that the goal of the gateway is to extract all the parts that have nothing to do with business development, such as permission control, routing, load balancing, and so on. We usually use spring to develop java applications. In the era of single application, the gateway and business code are mixed together, so it is not a big problem. However, in the scenario of distributed business development, our applications are usually deployed on different machines in different computer rooms, and there may be hundreds or even thousands of instances for each application. At this time, if you bind the gateway and the application, the strong coupling between them may greatly reduce the maintainability of the application. For example, the upgrade of the gateway may require all application instances to be updated at the same time, which is obviously very inconvenient. Therefore, we will specifically extract the business of the gateway, manage and maintain it separately. Spring cloud also has its own gateway implementation. You can see
controller can indeed do login and authentication, followed by business logic
. But if there is an api gateway, login and authentication can be done at the gateway layer. Controller is only responsible for specific business logic, which is conducive to code hierarchical isolation.
also helps to decouple
the function of the api gateway is very similar to that of nginx, except that you can write some authentication code in the gateway, so that you do not have to write authentication code in every underlying micro-service. Nginx, I believe that many people, including me, will not touch his code to write some of their own business logic.
first of all, you can use springmvc's controller to implement gateway functions, and you can even use springmvc's controller to implement gateway services.
but large organizations generally have a separate gateway, and the controller of the springmvc of the business system will only focus on the business, not on authentication, payload and these.