I. Introduction to MSA

1.1. What is MSA

Microservice Architecture MSA, short for Microservice Architect, is an architectural pattern that advocates partitioning a single application into a set of small services that communicate and collaborate with each other to provide ultimate value to users. The differences between it and SOA are as follows:

1.2. Our MSA framework

Our microservices framework, MSAFx.dll, is implemented in a Service Ack 4.0.60 wrapper. NET Web Services framework, and ServiceStack itself supports common lightweight protocols and Metadata. The main advantages of MsaFx over common Web Services frameworks such as WCF are as follows:

  1. High performance: Good performance and fast speed.
  2. Cross-platform support: Web Services developed based on MsaFx can run in both Windows and MonO-supported Linux environments.
  3. Supports multiple protocols: For example, XSD is supported in JSON format.
  4. More Web: RESTful.
  5. Complete decoupling of the server implementation from the client implementation: MSA is message-based so that changes to the server API do not break the existing client, so that the server implementation is completely decoupled from the client implementation.
  6. The MSA API visual documentation is easy to debug.
  7. Easy to learn: Developing and maintaining services using MSA requires much less technology and time.
  8. Ease of use: Simplifies the development process for REST and WCF SOAP-style Web Services.

1.3 MSA framework implementation architecture

The architecture of the MSA server is shown in the first figure, and the ARCHITECTURE of the MSA HTTP client is shown in the second figure. The internal MSA is built on the native ASP.NET IHttpHandler implementation, support JSON, XML, JSV, HTML, Message Pack, ProtoBuf, CSV and other Message formats.

Architecture of the MSA server

Architecture of the MSA HTTP Client

Second, the use of MSA framework

1. Service hosting

Before providing services externally, the server must be hosted. MSA provides the server to Host through IIS, self-host and other forms, the Host environment can be console application or Windows Service or ASP.NET Web application or ASP.NET MVC application. The provided MSA Demo is hosted in an ASP.NET Web application.

2, routing,

A. The default route provided by MSA is:

__Fri Dec 15 2017 10:11:38 GMT+0800 (CST)____Fri Dec 15 2017 10:11:38 GMT+0800 (CST) __ / [XML | json | | HTML JSV | CSV] / [reply | oneway] / [Request DTO name] [(? 1 = {value} & query parameter query parameter 2 = {value} &... & query parameter n = {value})]. __Fri Dec 15 2017 10:11:38 GMT+0800 (CST)____Fri Dec 15 2017 10:11:38 GMT+0800 (CST)__Copy the code

B. Create a custom route by using RouteAttribute or configuring the route in the host environment. The MSA Demo uses the method of configuring routes in the host environment to create custom routes.

3. How to verify the validity of the request parameters

If you need to verify that the request parameters are required or valid before submitting them, the validation logic must be written in a class derived from MSA AbstractValidator (see MSA Demo orderValidator.cs for an example). Then configure to enable authentication in the host environment:

__Fri Dec 15 2017 10:11:38 GMT+0800 (CST)____Fri Dec 15 2017 10:11:38 GMT+0800 (CST)__Plugins.Add(new ValidationFeature()); container.RegisterValidator(typeof(OrderValidator)); __Fri Dec 15 2017 10:11:38 GMT+0800 (CST)____Fri Dec 15 2017 10:11:38 GMT+0800 (CST)__Copy the code

4, service,

When you create an MSA Service, you must inherit the Service class from MSA.

5. MSA built-in client

5.1 MSA provides some easily accessible clients that implement the IServiceClient interface. The REST supported clients also implement the IRestClient interface.

These client objects include: JsonServiceClient, JsvServiceClient, XmlServiceClient, MsgPackServiceClient, ProtoBufServiceClient, Soap11ServiceClient, Soap1 2 serviceclient, etc.

As you can see from the name, the differences are in the supported serialization and deserialization formats. Because they implement the same interface, they are used in the same way and can be interchangeable.

ProtoBufServiceClient and JsonServiceClient are used in MSA Demo. When using ProtoBufServiceClient, you need to do the following:

A. In addition to reference msa. DLL, you also need to reference protobuf-net.dll.

B. The following configuration needs to be performed in the host environment:

__Fri Dec 15 2017 10:11:38 GMT+0800 (CST)____Fri Dec 15 2017 10:11:38 GMT+0800 (CST)__Plugins.Add(new ProtoBufFormat()); __Fri Dec 15 2017 10:11:38 GMT+0800 (CST)____Fri Dec 15 2017 10:11:38 GMT+0800 (CST)__Copy the code

DataMember(Order = {0})] must be assigned to each attribute of the Request DTO and Response DTO objects. For details, see ProductreQuestDto. cs and productresponsedto. cs of MSA Demo.

5.2 The built-in MSA client provides Get, Send, Post, Put, Delete and other methods. Query data generally use Get method, new operation generally use Post method, update operation generally use Put method, Delete operation generally use Delete method. These methods all have overloads.

Here is one of the signatures of the Get method:

__Fri Dec 15 2017 10:11:38 GMT+0800 (CST)____Fri Dec 15 2017 10:11:38 GMT+0800 (CST)__TResponse Get<TResponse>(IReturn<TResponse> requestDto); __Fri Dec 15 2017 10:11:38 GMT+0800 (CST)____Fri Dec 15 2017 10:11:38 GMT+0800 (CST)__Copy the code

6. Realization of automatic generation of MSA API visual documentation

Add the following configuration to the host environment:

__Fri Dec 15 2017 10:11:38 GMT+0800 (CST)____Fri Dec 15 2017 10:11:38 GMT+0800 (CST)__Plugins.Add(new SwaggerFeature()); __Fri Dec 15 2017 10:11:38 GMT+0800 (CST)____Fri Dec 15 2017 10:11:38 GMT+0800 (CST)__Copy the code

If you want to see the description of each Request parameter and Response in the MSA API visual description document, you need to mark each attribute of the Request DTO and Response DTO object with ApiMember. The code is as follows:

__Fri Dec 15 2017 10:11:38 GMT+0800 (CST)____Fri Dec 15 2017 10:11:38 GMT+0800 (CST)__public class OrderRequest : IReturn<OrderResponse> {[ApiMember(Name = "Id", Description = "Id", IsRequired = false)] public int Id {get; IReturn<OrderResponse> {[ApiMember(Name = "Id", Description = "Id", IsRequired = false)] public int Id {get; set; } [ApiMember(Name = "CustomerName", Description = "CustomerName", IsRequired = false)] public String CustomerName {get; set; } / /... [ApiMember(Name = "OrderItemList", Description = "List of products ordered ", IsRequired = false)] public List<OrderItem> OrderItemList { get; set; } }__Fri Dec 15 2017 10:11:38 GMT+0800 (CST)____Fri Dec 15 2017 10:11:38 GMT+0800 (CST)__Copy the code

The running results are as follows:

Display the meaning of each request parameter and response in the MSA API visual description document

7. Running results

Run the managed application (such as the ServiceHost project in MSA Demo) and the Metadata page shown in the following figure appears. Then run the client to invoke the microservice; Data can also be viewed through a browser, and the url input format is as follows:

__Fri Dec 15 2017 10:11:38 GMT+0800 (CST)____Fri Dec 15 2017 10:11:38 GMT+0800 (CST)__http://localhost:34833/orders/1.html? CustomerName= Customer _1&istakeAway =true&StatusCode= 1&createdDate =2017-08-21 10:58:48.230__fri Dec 15 2017 10:11:38 GMT+0800 (CST)____Fri Dec 15 2017 10:11:38 GMT+0800 (CST)__Copy the code

Or:

__Fri Dec 15 2017 10:11:38 GMT+0800 (CST)____Fri Dec 15 2017 10:11:38 GMT+0800 (CST)__http://localhost:34833/html/reply/GetOrderRequest? Id= 1&customerName = customer 1&istakeAway =true&StatusCode= 1&createdDate =2017-08-21 10:58:48.230__frI Dec 15 2017 10:11:38 GMT+0800 (CST)____Fri Dec 15 2017 10:11:38 GMT+0800 (CST)__Copy the code

The first url format rule is the custom routing rule configured in MSA Demo in the host environment, and the second url format rule is the default routing rule provided by MSA.

Click [MSA API UI] on the Metadata page shown in the following figure, and enter the MSA API visual description document interface shown in the following figure. Developers can debug the document automatically generated by MSA, which is very convenient.

The Metadata page

MSA API visual documentation interface

Third, micro-service governance

Interface registration is carried out in our independently developed framework management system, as shown in the figure below. Among them, the regulations of internal Service access naming conventions are: / Service} {* * * / method name, such as/OrderService/CreateOrder; OpenApiName is named as follows: {abbreviation of each product line} Method name, for example, FltCreateOrder, where Flt indicates the abbreviation of domestic air ticket service.

MSA interface registration page

Microservices Gateway API Gateway

4.1 introduction to API Gateway

The core idea of the API Gateway style is to use a lightweight message Gateway as the main entry point for all clients and to implement common non-functional requirements at the API Gateway level. As shown below: All services are exposed through the API gateway, which is the only access point for all clients; If a service wants to access another service, it also goes through this gateway.

All services are exposed through an API gateway

Once the API gateway allows clients to consume a managed API, then we can use it as a managed API to expose the business logic implemented by the microservice. API gateways use NIO and IOCP to connect internal managed apis to achieve high concurrency of API gateways.

4.2. Advantages of API Gateway

  • Network isolation: Microservices are deployed on the Intranet and open to PartnerAPI, WebAPI, or MobileAPI through the API Gateway.
  • Lightweight message routing and transformation at the gateway level.
  • Provide the necessary abstraction for existing microservices at the gateway level. For example, gateways 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, fuses, monitoring, logging, and so on.
  • By applying the API gateway pattern, microservices can become more lightweight because non-functional requirements are implemented on the gateway.
  • Unified security control.

4.3 Architecture of API Gateway

4.4 Functions of API Gateway

The API Gateway provides the following functions:

  1. Route mapping: External service access names are mapped to corresponding internal service access names.
  2. Permission authentication: includes customer role authentication, customer access authorization authentication, and IP blacklist authentication.
  3. Timeout handling: When the internal service response time of the API gateway call exceeds the maximum allowed timeout time set in the self-developed API gateway background management subsystem, THE API gateway will immediately stop the call and return the relevant message to you.
  4. Traffic limiting: When you call an internal service through the API gateway at a certain rate, the API gateway will immediately disconnect the service. When the time passes, the link is automatically closed.
  5. Fusing: Fusing is particularly useful to avoid unnecessary resource consumption. When the frequency of an internal service called through the API gateway reaches a certain threshold, the API gateway will do a temporary fusing, which is to temporarily disconnect the link and stop your calls to that internal service. After a temporary fusing, the link is automatically closed after a period of time.
  6. Log information: Records customer IP addresses, customer request parameters, returned results, and exceptions.

4.5. Use of API Gateway

Before using API Gateway, you need to configure Gateway parameters. The configuration of gateway parameters is carried out in the independently developed API gateway background management subsystem:

The gateway parameters are configured in the self-developed API gateway background management subsystem

5. Demo download and more information

  • MSADemo download address: github.com/das2017/MSA…
  • APIGatewayDemo download address: github.com/das2017/Api…
  • ServiceStack website: Servicestack.net/

The list of topics covered in this series is as follows. If you are interested, please pay attention:

  • Introduction: Small and medium-sized R&D team architecture practice three points
  • Cache Redis: Quick start and application of Redis
  • Message queue RabbitMQ: How to use the good news queue RabbitMQ?
  • Centralized log ELK: A centralized log ELK of architectural practices for small and medium r&d teams
  • Task scheduling Job: Task scheduling Job in the architectural practice of small and medium-sized R&D teams
  • Metrics: What does app monitoring do?
  • Microservices framework MSA
  • Solr
  • Distributed coordinator ZooKeeper
  • Small tools:
  • Dapper.NET/EmitMapper/AutoMapper/Autofac/NuGet
  • Release tool Jenkins
  • Overall architecture design: How to do e-commerce enterprise overall architecture?
  • Single project architecture design
  • Uniform application layering: How to standardize all application layering in a company?
  • Debugging tool WinDbg
  • Single sign-on (sso)
  • Enterprise Payment Gateway
  • “Article

The authors introduce

Yang Li has years of experience in Internet application system research and development. She used to work in Gooda Group and now works as the system architect of Zhongqing E-Travel. She is mainly responsible for the architecture design of the business system of the company’s R&D center, as well as the accumulation and training of new technologies. The current focus is on open source software, software architecture, microservices and big data.

Zhang Huiqing, an IT veteran of more than 10 years, has successively served as architect of Ctrip, chief architect of Gooda Group, CTO of Zhongqing E-Travel and led the upgrading and transformation of the technical architecture of the two companies. Focus on architecture and engineering efficiency, technology and business matching and integration, technology value and innovation.

Thanks to Yuta Tian guang for correcting this article.