Microservice framework developed by. Net core


Microservice development framework integrating. Net core + swagger + consult + Polly + Ocelot + identityserver4 + exceptionless + Apollo

GitHub source code address


Apollo configuration center

Apollo (Apollo) is a distributed configuration center developed by Ctrip framework department. It can centrally manage the configuration of different application environments and clusters. After configuration modification, it can be pushed to the application end in real time. Moreover, it has the characteristics of normative authority and process governance, which is suitable for microservice configuration management scenarios. Since each project configuration needs to read the basic configuration information, the Apollo environment is deployed on CentOS (101) of the intranet, and some basic configuration information is added for the project. The configuration is shown in the figure below


Consult is a service grid solution, providing services discovery, health check, key / value storage, multi data center and other functions. Start the consult service in Intranet 101. For testing, the user service instances are started locally on three ports. In actual production, these services may be deployed in different computer rooms and different machines. They form a service cluster. The service provides a heartbeat detection method to detect whether the service instance is healthy at regular time. When the service is started, it is in C One registration in onsul is often referred to as service registration and discovery. The screenshots of three service instances are shown below

After the registration is completed, open the UI interface of consult, and you can see that there is one more cluster group name of user service in the list: Demo.MicroServer.UserService , as shown in the figure

click Demo.MicroServer.UserService After entering, the information of the three service instances is shown as shown in the figure


Swagger provides a visual UI page presentation description file. The caller and test of the interface can check the relevant interface and make some simple interface requests in this page. Of course, the functions of swagger are far more than these. In the project, swagger has been connected to the service instance, as shown in the figure below

Because the three service instances are the same code, you can see the swagger addresses of the three ports, and the interface information is completely consistent.

Ocelot gateway

Ocelot is a. Net API gateway, which provides routing, request aggregation, There are a series of powerful functions, such as service discovery, authentication, current limiting and fusing, load balancer and so on For example, we can see the API related document information when we open the ports of the three service instances, but whether we can directly integrate it in the API gateway? The answer is yes. This depends on the powerful routing function of ocelot. As shown in the figure, after a few simple lines of configuration, we configure the swagger into the gateway

The use of the load balancer built into the gateway is shown in the figure below. I made three calls to the same interface in the gateway, and I can see that the results come from three different ports, because I chose the polling strategy in the load balancer

Current restriction policy: when we configure and enable the current restriction policy and configure the limit of access times per unit time, then quickly refresh the interface. If the number of times exceeds the set limit, you can see that the error prompt appears


Exceptionless is an open source real-time log collection framework. I believe that in microservice architecture or distributed applications, there should be a unified log collection function. Exceptionless provides a good service. I believe that many developers are using elk to complete log collection. Here, the bottom layer of exceptionless is also based on elasticsearch, Exceptionless provides two service methods. One is online, which is to register an account directly on the official website and create new projects. The official will assign an appid to each project, and configure the ID to the project for use. Of course, online use is limited. There are restrictions on the number of log collection (3000) and storage time (3 days). There should be no questions about test or temporary use Considering that the later projects will be used in the production environment, I built a localized exceptionless environment on the intranet CentOS to collect logs. Here I call an exception collection test interface written in swagger

After sending, go to the UI interface of exceptionless to check the collection

You can see that there is one more data record of sending test in the interface

Identity server 4 unified authentication center

The authentication and authorization are put at the end, because without this, the process can run smoothly. When testing, if you find this part of the test troublesome, you can comment it out first, and then integrate it after the process runs through. There are many usages of this thing. Here, we integrate identityserver4 into the API gateway to complete unified authentication and authentication. In the identityserver4 project, implement the following classes

Classification to complete a few things: definition of API resources, client access resource scope, account password verification process and data return format Then, in the API Gateway project, we need to explain why we need to integrate identityserver4 into the gateway, instead of authenticating each service instance separately. Imagine if in a large project, different groups maintain different service instances, it is bound that each team must complete a set of authentication logic in their own code However, Ocelot naturally integrates identityserver4 well. We only need to add authentication code in the gateway, and each microservice instance only needs to care about its own business logic code. This also lists the use process. When the client does not have a token to access the API resources through the gateway, you can see the return status code as shown in the figure: 401

Then we go to identity server 4 to request a token

After getting the token, take the token and request the same API resource through the gateway. You can see that you get the desired resource correctly.

Special instructions

All the above instructions are reflected in the code and are open to the public. However, for a complete microservice architecture, it is still too brief. It just gives a brief description. It will be separated and shared in the future. As for why to do this and how to install the tools, there are a lot of comparisons and tutorials in the blog Garden and other places. Here, we focus on the implementation of the microservice architecture. We welcome your valuable opinions. Of course, we welcome star if it is helpful to you
Microservice framework developed by. Net core

Recommended Today

Intensive reading of design pattern abstract factory Abstract Factory

Abstract factory is a kind of creation pattern. The abstract degree of factory class pattern is simple factory pattern, factory pattern and abstract factory pattern. Intent: provide an interface to create a series of related or interdependent objects without specifying their specific classes. For example If you don’t understand the above intention introduction, it doesn’t […]