I Background:
Previously, I shared a microservice development framework“ Enjoy an integration Net core+swagger+consume+poly+ocelot+identityserver4+exceptions+apollo+skywalking ”Two days ago, I received an Issues on Github to provide me with complete operation documents and configuration files. The idea was that after I had made clear the responsibilities of these things, I should know the sequence of operations and the required configuration key s. Therefore, the README compilation only introduced what was used, not how to run it. However, since someone asked, I was satisfied, Just think of it as a self review.
II Review the project structure
The project structure is relatively simple:
- Microserver The instance folder contains microservice instances. As for the splitting of microservice granularity, it should be combined with the actual business situation
- Demo Microserver Identityserver4 unified authentication center
- Demo Microserver Infrastructure Infrastructure, where you can add content by yourself
- Demo Microserver The ocelot layer is the Api gateway
- Demo Microserver The common data access layer of the repository, including MySQL, Mongo, Redis, etc., is separated to facilitate each service instance to directly use these common methods.
However, there are several things in the above-mentioned ".Net core+swagger+Consul+polly+ocelot+identityserver4+exceptions+apollo+SkyWalking" that have not yet appeared. They are Consul, Polly, exceptions, Apollo and SkyWalking. Let's introduce them respectively
- Consul is a service grid solution that provides service discovery, health check, Key/Value storage, multi data center and other functions. Here we mainly use the service discovery, health check and startup scenarios: when the microservice instance is started
- Polly yes NET elastic and transient fault handling library, which is naturally and friendly integrated with Ocelot, can be used only by adding a few configurations in the ocelot layer
- Exceptionless is an open source real-time log collection framework. It can use online or locally built services (it is convenient to directly use online services if only local tests are recommended). Then it can be used after configuring the Url and the application's ApiKey in the microservice.
- Apollo is a distributed configuration center developed by Ctrip framework department. It can centrally manage the configuration of different environments and clusters. After the configuration is modified, it can be pushed to the application end in real time. It also has standardized permissions, process governance and other characteristics. It is suitable for micro service configuration management scenarios. After the Apollo service is built, our code configuration file can become quite clean. Only the configuration of Apollo can be left, Almost all other configurations can be placed in Apollo.
- SkyWalking I have an article about SkyWalking that specifically introduces this. I won't repeat it here. You can check what you need to know: In the microservice framework demo Add skywalking+skyapm dotnet distributed link tracking system to microserver
III Install and start microservice peripheral application
Before running the service, you may install or start the following services
- MySql
- Exceptionless If not already installed, refer to: https://github.com/exceptionless/exceptionless/wiki/self-hosting , it is recommended to install using docker
- apollo If not already installed, refer to: https://github.com/ApolloAuto/apollo/blob/master/docs/quickstart/apollo_software_installation_guide_cn.md
- consul You can download the compiled file directly and start it directly ./consul agent -dev -data-dir=/data/consul -node=agent-1 -client=0.0.0.0 -bind=10.34.5.101 -datacenter=demo
- Skywalking Please refer to my previous article: In the microservice framework demo Add skywalking+skyapm dotnet distributed link tracking system to microserver
Do you feel flustered when you see so many things that need to be installed and started? Don't worry. In fact, if you exclude authentication and don't even need to read the database, you can just install consumer. As for apollo, you can first write the configuration in the configuration file of the code. For running the project, apollo is not necessary. Log collection can also be suspended. Performance testing is the same. We can run the core first, and then improve its surroundings. With this idea, we start running
IV Start up
-
Start consumer
Under development, we can start the consumer service as follows:
./consul agent -dev -data-dir=/data/consul -node=agent-1 -client=0.0.0.0 -bind=10.34.5.101 -datacenter=demo
The effect after startup is shown in the figure:
-
Start three microservice instances
dotnet Demo.MicroServer.UserService.dll --urls="http://*: 6891 "--ip=" local IP "--port=6891 dotnet Demo.MicroServer.UserService.dll --urls="http://*: 6892 "--ip=" local IP "--port=6892 dotnet Demo.MicroServer.UserService.dll --urls="http://*: 6893 "--ip=" local IP "--port=6893
It is demonstrated here that the user's microservice instance is started on the three ports 689168926893 respectively. After starting, the consumer starts to work, as shown in the figure:
How Consul discovers services actually benefits from an extension we added to the service:
public static IApplicationBuilder UseConsul(this IApplicationBuilder app, IConfiguration configuration)
{
ConsulClient _client = new ConsulClient(c =>
{
c.Address = new Uri(configuration["Consul.ServerUrl"]);
c.Datacenter = "Demo.MicroServer";
});
string ip = configuration["ip"];
int port = int.Parse(configuration["port"]);
int weight = string.IsNullOrEmpty(configuration["weight"]) ? 1 : int.Parse(configuration["weight"]);
_client.Agent.ServiceRegister(new AgentServiceRegistration()
{
ID = "UserService-" + Guid.NewGuid(),
Name = "Demo.MicroServer.UserService",
Address = ip,
Port = port,
Tags = new string[] { string.IsNullOrEmpty(configuration["tags"]) ? "" : configuration["tags"] }, //label
Check = new AgentServiceCheck() //Health examination
{
Interval = TimeSpan.FromSeconds(10), //How often is it tested
HTTP = $"http://{ip}:{port}/api/health/check",
Timeout = TimeSpan.FromSeconds(5),
DeregisterCriticalServiceAfter = TimeSpan.FromSeconds(60) //Close its own service channel after encountering an exception
}
});
return app;
}
And on startup CS uses: app Useconsult (configuration);
In fact, the project has already started and has a preliminary load balancing function. We can call services through any of the three ports. There are all kinds of services. However, should we manually configure which ip and port services to use in any scenario, or should we expose all our services and add a set of login authentication mechanism to each service? It's terrible to think about it, so how to solve this problem? The answer is Net: Ocelot
-
Start gateway Ocelot
Start the ocelot layer: dotnet demo Microserver Ocelot DLL After the gateway is started, any registered service can be accessed through the ip of the gateway. The premise is that the protocol is configured in the gateway layer. Take the following two examples: one is swagger and the other is user service
//swagger
{
"DownstreamPathTemplate": "/doc/Demo.MicroServer.UserService/swagger.json",
"DownstreamScheme": "http",
"ServiceName": "Demo.MicroServer.UserService",
"LoadBalancer": "RoundRobin",
"UseServiceDiscovery": true,
"UpstreamPathTemplate": "/doc/Demo.MicroServer.UserService/swagger.json",
"UpstreamHttpMethod": [ "GET", "POST", "DELETE", "PUT" ]
},
//UserService
{
"DownstreamPathTemplate": "/api/{url}",
"DownstreamScheme": "http",
"UpstreamPathTemplate": "/api/{url}",
"UpstreamHttpMethod": [ "Get", "Post", "DELETE", "PUT" ],
"ServiceName": "Demo.MicroServer.UserService",
"UseServiceDiscovery": true,
"LoadBalancerOptions": {
"Type": "RoundRobin"
},
Since the swagger document has been configured in each service, only the routing protocol needs to be specified here, and swagger can be accessed through the gateway Here, you can access the swagger and userservice services through the ip and port of the gateway
Up to now, the service registration and discovery as well as the upstream and downstream configuration of the gateway have been basically completed. However, there are many things around the gateway layer, such as caching, current limiting, fuses, unified authentication at the gateway layer, etc., but these are not currently to be discussed. We will see whether we need to explain them separately according to the follow-up feedback
V Apoll o configuration
The above describes the operation startup process. According to the requirements, the general configuration items of apollo are also pasted here. The configuration of the gateway layer and user service layer are configured in appsetting, and they are already in the code. Here, the configuration in apollo is emphatically pasted
- Demo Microserver Configuration of Ocelot layer in apollo:
Swagger.ServiceDocNames = Demo.MicroServer.UserService,Demo.MicroServer.ProductService IdentityService4.Uri = http://localhost:5000 IdentityService4.UseHttps = false
As shown in the figure:
- Demo Microserver Configuration of userservice layer in apollo:
MySqlConnections = server=mysql_ip;port=3306;database=demo_microserver;User Id=root;pwd=123456;charset=utf8 Swagger.Name = Demo.MicroServer.UserService Swagger.Version = v1 Swagger.DocName = Demo.MicroServer.UserService Swagger.Title = Api interface documentation Swagger.Description = See below for specific interface Swagger.Contact.Name = PeyShine Swagger.Contact.Email = PeyShine@qq.COM Swagger.XmlFile = Demo.MicroServer.UserService.xml Exceptionless.ApiKey = LmqMIxSTW0U68pKwJ3xXqrNrLqS6oEociW7OexNt Exceptionless.ServerUrl = http://exceptionless_ip:5000 Consul.ServerUrl = http://consul_ip:8500 MongoDB.DefaultConnection = mongodb://dev:Aa123456@mongo_ip/demo_db MongoDB.DefaultDatabase = demo_db MongoDB.DefaultTable = users
As shown in the figure:
Vi summary
This article as an article“ Share an integration Net core+swagger+consume+poly+ocelot+identityserver4+exceptions+apollo+skywalking "Is a supplementary extension of the. It mainly introduces how to start the Demo.MicroServer microservice framework step by step. There is no in-depth discussion about the gateway and IdentityServer4. The idea is that as long as the core part of the project can be run first, peripheral applications can be added by themselves, and then it will be introduced in more detail according to the feedback. In fact, after understanding the responsibilities of several open source projects, it is not difficult to understand the operation process. Let's try it!
Address of article code in Github: https://github.com/PeyShine/Demo.MicroServer Welcome, star