. NET micro-service architecture and API gateways

I. Overview of MSA1.1. What is MSA?microservices Architecture MSA is the abbreviation for Microservice architecture, an architectural model that advocates dividing a single application into a small set of services, communicating and cooperating with each other, providing the ultimate value to the user. the difference between it and SOA is as follows:

SOA implementation	Micro-Service Architecture implementation
Enterprise-class, top-down implementation	Team-level, bottom-up implementation
Large granularity: Services are made up of multiple subsystems	Granular: One system is split into multiple services, and the service definition is clearer
Re-ESB: Enterprise service Bus, centralized service architecture	Light Gateway: No centralized bus, loose service architecture
Complex development process	Easy to develop: reduces the complexity of enterprise ESB development and is highly integrated with the idea of agile development
Single-block architecture system, interdependent, complex deployment	Services can be deployed independently

1.2. Our MSA Frameworkour microservices framework , MsaFx.dll, is a. NET WEB Services Framework that is implemented based on Servicestack 4.0.60 packaging, and Servicestack natively supports a common lightweight protocol and metadata. Msafx The main advantages compared to the normal Web Services framework such as WCF are as follows : 1, High performance: good performance, fast speed. 2. Support cross-platform operation: The Web services developed based on M-Safx can run in a Windows environment and in a Linux environment that supports mono. 3. Support Multi-protocol: XSD is also supported in JSON format. 4, more Web:RESTful. 5, service-side implementation and client implementation of the full decoupling:MSA based on message design, so that the service side of the API changes will not destroy the existing client, to achieve the service-side implementation and the client to fully decouple the purpose. 6 . The MSA API visual documentation is easy to debug. 7, easy to learn: the use of MSA for development and maintenance services required by the technical and time investment is much smaller. 8. Ease of use: simplifies the development of rest and WCF soap-style Web services. 1.3. MSA Framework Implementation ArchitectureThe architecture of the MSA server is shown in the first diagram, the HTTP client architecture for MSA see the second diagram. The internal MSA is built on top of the native ASP. IHttpHandler, which supports JSON, XML, JSV, HTML, message Pack, PROTOBUF, CSV, and other messaging formats. the architecture of the MSA server  the architecture of the MSA HTTP clientIi. use of the MSA framework1. Service HostingService- side services must first be managed before they can be serviced externally. MSA provides a host of services hosted by IIS, Self-host, and other forms, which can be console applications or Windows service or ASP. The MSA demo hosted environment is provided with an ASP. NET Web application. 2. RoutingA, the default route provided by the MSA itself is:/[xml|json|html|jsv|csv]/[reply|oneway]/[request dto name] [(? query parameter 1={value}&query parameter 2={value}& ... &query parameter n={value})]. B. Create a custom route by using Routeattribute or configuring it in a hosting environment. The MSA demo provided provides a way to create a custom route in a hosted environment that is configured for routing. 3. How to verify the legality of request parametersIf you need to verify that the request parameters are mandatory or legitimate before submitting the request parameters, the validation logic must be written in the Abstractvalidator<trequest> class that inherits from MSA (see the MSA for an example Demo OrderValidator.cs), and then the configuration to enable authentication in the hosting environment:

1 Plugins.add (New Validationfeature ()); 2 container. Registervalidator (typeof (Ordervalidator));

4. ServiceWhen you create an MSA service, you must inherit the service class from the MSA. 5. MSA built-In client 5.1. TheMSA has built-in clients with convenient access, all of which implement the IserviceclienT interface, where the rest-enabled client also implements the Irestclient interface. These client objects include: Jsonserviceclient, Jsvserviceclient, Xmlserviceclient, Msgpackserviceclient, Protobufserviceclient, Soap11serviceclient, Soap12serviceclient and so on. As you can see from the name, there are several differences between the supported serialization and deserialization formats. Because they implement the same interface, they are used in the same way and can be replaced by each other. The MSA demo uses both the Jsonserviceclient and protobufserviceclient clients, where you need to do the following when using the Protobufserviceclient client:A, in addition to the need to reference MSA.dll, you also need to reference protobuf-net.dll. B. The following configuration is required in the hosting environment:

1 Plugins.add (New Protobufformat ());

C, each property of the request Dto object and the response Dto object must be marked with the [DataMember (Order = {0})] attribute, as described in the MSA Demo of ProductRequestDTO.cs and ProductResponseDTO.cs.

  5.2,MSA built-in client provides get, Send, Post, Put, Delete and other methods. Query data generally with Get method, the new operation is generally used post method, update operation generally with put method, delete operation general with Delete method. These methods all have overloads. The following is one of the signatures of the get method:

1 tresponse get<tresponse> (ireturn<tresponse> requestdto);

6, MSA API Visual description of the implementation of automatic document generationin the hosting environment, add the following configuration:

1 Plugins.add (New Swaggerfeature ());

If you need to be able to see the description of each request parameter and response in the MSA API visual documentation, then you need to mark the Apimember for each property of the requests Dto, Response Dto object, and the code reference is as follows:

1 public class Orderrequest:ireturn<orderresponse> 2 {3    [Apimember (Name = "id", Description = "Order ID number", isrequ  Ired = False)] 4 public    int Id {get; set;} 5    [Apimember (name = "CustomerName", Description = "Customer Name", IsRequired = FALSE)] 6 public    string CustomerName {get; set;} 7    //... 8    [Apimember (Name = "Orderitemlist", Description = "Ordered Product List", IsRequired = False)] 9 public    list<orderitem& Gt orderitemlist {get; set;} 10}

the results of the operation are as follows: show the description of each request parameter and response in the MSA API visual documentation7. Operation ResultRun the managed app first (such as the ServiceHost project in the MSA demo), and the metadata page shown appears. Then run the client to invoke the MicroServices, or you can view the data via the browser, and the URL input format is as follows:   / http localhost:34833 / orders /1.html? CustomerName = Customer _1&istakeaway=true&statuscode=1&createddate=201 7 -0 8 -21 10:58:48.230Or: /http L ocalhost:34833 /html/reply/ Getorderrequest? Id=1&customername = Customer _1&istakeaway=true& statuscode=1&createddate=201 7 -0 8 -21  10:58:48.230 Span class= "author-3423802", where the 1th URL format rule is the custom routing rule in the MSA demo in the hosting environment, and the 2nd URL format rule is the default routing rule provided by MSA. after clicking on the "MSA API UI" in the metadata page shown, it is convenient to enter the MSA API Visual Description document interface, which can be debugged by the MSA automatically generated documentation. Metadata Page MSA API Visual Description document interface third, micro-service governancein our self-developed framework management system, interface registration, please see. where the naming convention for internal service access names is:/{***service}/method names, such as/orderservice/createorder; Specifies that the naming convention for the external service access name Openapiname is: {abbreviated English name} for each product line} method name, such as Fltcreateorder, which Flt represents the domestic airline business abbreviation English name. MSA Interface Registration pageIv. Micro-service gateways API Gateway4.1. Introduction to API GatewayThe core idea of the API Gateway style is to use a lightweight message gateway as the main portal for all clients and to implement generic non-functional requirements at the API Gateway level. As shown: All services are exposed through the API gateway, which is the only entry for all client access, and if one service wants to access another service, pass through the gateway. all services are exposed through an API GatewayOnce the API gateway allows clients to consume a managed API, we can use it as a managed API to expose the business logic implemented by this microservices. The API Gateway connects the internal managed API with NIO, IOCP to enable high concurrency for API gateways. 4.2. Advantages of API Gateway

• Network isolation: MicroServices are deployed in the intranet and open to Partnerapi, Webapi, or Mobileapi via API Gateway.

• Lightweight message Routing and transformation at the gateway level.

• Provides the necessary abstraction for the presence of microservices at the gateway level. For example, a gateway can choose to expose different APIs to different users.

• A central place provides non-functional capabilities that can be reused, such as timeouts, current limiting, fusing, monitoring, and logging.

• By applying the API gateway pattern, microservices can become lighter because non-functional requirements are implemented on the gateways.

• Unified security Control.

4.3. Architecture of API Gateway4.4. Function of API Gateway API Gateway mainly implements the following functions: 1. Route map: the external service access name is mapped to the corresponding internal service access name. 2, Authorization authentication: including access authorization authentication for customer role, authorization authentication for customer, IP blacklist authentication. 3. Timeout processing: when the API Gateway invokes an internal service response time that exceeds the maximum allowable timeout set in the self-developed API Gateway background management subsystem, the API gateway stops the call immediately and returns the relevant message to you. 4, current limit control: When you call the internal service through the API Gateway frequency reached at a certain threshold, the API Gateway will immediately do the disconnection link processing. After a time, the link will automatically close back. 5, fuse processing: fuse processing is particularly useful to avoid unnecessary resource consumption, when the internal service called through the API gateway to a certain threshold of frequency, then the API Gateway will do a temporary blow-off to temporarily disconnect the link, Temporarily stop your call to that internal service. After a short period of time, the link will automatically close back after a temporary fuse. 6, log information records: customer IP, customer request parameters, return results, abnormal information and other information. 4.5, the use of API gatewaybefore using API gateway, you need to configure the gateway parameters first. The configuration of gateway parameters is done in the self-developed API Gateway background management subsystem: configuring gateway parameters in the self-developed API Gateway background management Subsystemv. Demo download and more information

• Msademo:Https://github.com/das2017/MSADemo

• Apigatewaydemo:Https://github.com/das2017/ApiGatewayDemo

• Servicestack Official website:https://servicestack.net/

Original link: https://www.cnblogs.com/dotnet-arch-system/p/8504602.html

. NET micro-service architecture and API gateways