Thoughts and changes in microservice frameworks-Basic OSS. Core Ideas and frameworks-oss. core

Thoughts and changes in microservice frameworks-Basic OSS. Core Ideas and frameworks-oss. core

Today, the frameworks are already broken, and the architecture design of xx Company can be seen everywhere. However, most of them look at the excitement. How are these frameworks come about, and how do we think about the details, what is the basis for mutual isolation... I believe that many of my friends still have their own doubts, especially the increasingly popular microservice and derivative microservice gateway products. I plan to write a small open source framework OSS recently. core, there is a bit of thinking in the process. I will record this article and try to help you understand it as much as possible. It will probably focus on the following issues:

1. Origins of microservices
2. microservice design ideas
3. Design and Implementation of the OSS. Core framework

Before proceeding, I hope that you will first understand that the traditional architecture and microservice architecture are not mutually independent or independent, microservice is a logical concept derived from the traditional framework to cope with concurrent maintenance and other issues. It is more about the transformation of thinking and solving methods at different stages of the project. Secondly, the logical architecture and physical architecture (Files) are separated. Most of the time, the logical architecture corresponds to the physical architecture. However, sometimes a physical architecture can contain multiple logical architectures.

I. Origins of microservices

Microservices mainly split some large and complex applications into multiple service combinations. Each Service is autonomous to achieve more flexible and convenient maintenance.

For better understanding, Let's first look at three common ways to solve concurrency:

1. Add mechanisms such as master-slave database separation, or even multi-master write or partition. Modify the connection string or add access middleware in the application to improve the processing capability of the database.

2. Because the database resources are relatively tight and time-consuming, in order to improve the access speed, distributed cache is usually used to reduce access to the underlying layer.

3. Server Load balancer (SLB) is distributed to different machines before a large number of requests reach the application to solve the bandwidth and performance bottleneck of a single machine.

Of course, there are many other ways to solve concurrency, such as front-end static File compression, CDN acceleration, IP speed control, etc., which are skipped here.

The above three methods should have been seen by many friends. The reason for listing them here, combined with this figure, can be more easily compared with the changes between traditional services and microservices:

In the traditional overall service framework, there is a large coupling between modules, there are mutual calls within the project, and various complex aggregation operations, so in most cases, only the overall deployment can be achieved, in the left-side figure, we can see that we need to deploy the Server Load balancer on multiple machines as a whole. This is also true for databases, and the requirements for each module in a project are different.

For example, the Access frequency and process complexity of products and order modules vary greatly. The order frequency is relatively small and the complexity is high, we also hope to run on a relatively small number of machines with high budget capabilities and facilitate troubleshooting and maintenance. The picture on the right shows that after the service is refined, we can use smaller deployment units to make combinations based on the situation.

At the same time, in today's rapid iteration of Internet products, a product requires the ability to quickly launch different application functions for different terminals, and business adjustments can be quickly launched, the traditional overall service model is insufficient. Microservices have been reduced to zero, but because the independence of each module can quickly combine with each other, and each module can adopt programming languages with different features according to different requirements.

　　

 

Ii. microservice design ideas

Because each product has its own standards and priorities, the design of service units varies with each other, but there is a basic point:Service autonomy

When designing a microservice module, you must ensure the independence of the current service, especially the independence of the data module. Other services do not have the right to directly operate the database module under the current service, external interaction can only be completed through the service interface. Because the modules are independent, you can select the appropriate programming language and the corresponding deployment scale. Achieve local flexible optimization. While microservices are independent of each other, they also bring about some problems we need to face:

　　First:How to define the boundaries of the current service and determine the scope of the current service governance.

To minimize the number of service units, we need to determine the responsibility boundary of the service. We recommend that you consider the following:Service Lifecycle Process,Fields, AndEstimated Scale These considerations, such as user services, can be used to place basic user information and balance accounts under a service module when there are few visitors, so as to reduce workload and reduce energy dispersion. When the scale is large, basic services and asset services are further divided.

　　Second:Cross-Service Data Query

For example, you can search for products on the client, search for users, or query statistics. I will give two processing methods for this:

1. API Gateway

This situation is suitable for scenarios where there are too many service units. The client needs to query data in different service units. In this case, we can build an API Service Gateway (which should be separated from the APP Gateway ), the gateway aggregates multiple services and the client only needs to interact with the current Gateway. The Gateway aggregates and forwards the services to different microservices. For example:

2. data redundancy or background data synchronization

For example, in order information, I need a small number of user fields such as the user name. In this case, we can completely redundant these fields under the Order microservice data module. For example, in the statistics module, the data producer and the queryer are completely different objects without high real-time performance. Therefore, we recommend that you create a statistical service and a corresponding statistical database, other services update the corresponding statistical data through event message interaction. You can complete the query by counting the data of the service itself.

　Again:How to solve inter-service communication problems

Because we have isolated services from each other and cut off the possibility of direct operations on different service databases. So how can we deal with data consistency? In traditional service models, we can ensure data consistency through transactions or stored procedures because they are all combined. There are two common methods:

1. asynchronous event message-driven

This type of solution is suitable for scenarios with relatively low real-time requirements for data, such as the above statistics service updates, and message notifications that push responses to message queues after service events such as orders are triggered, the service that subscribes to this queue receives updated data.

2. Direct Interface request (HTTP, RPC)

Generally, it is not recommended to avoid cascading dependency. This type of request mainly targets requests with high real-time data requirements. For example, you need to immediately know whether the inventory service deduction is successful during the second kill order process. (Note: The support for tasks in. net is particularly good. asynchronous http requests are recommended, and the frontend returns the task <ActionResult> to reduce the worker thread consumption caused by IO operations)

　　Finally:How to access the client

After we encapsulate the service, how the service is accessed from the final client depends on the actual security rules and requirements. Generally, if the service is relatively small, if the functions are not complex, you can directly expose the service interface to the client for access,

OrAPI GatewayOf course, there are also many mature microservice gateways such as Service Fabric or API Management on Azure cloud.

 

Iii. OSS. Core framework ideas and implementation

OSS. the Core project is a small open-source product I recently wrote. I should know that I have written some components like OSS. social, OSS. payCenter, OSS. common, OSS. the Http Project hopes to connect these components. The above section describes the general way of thinking about microservices. I will try to reflect this in the logical architecture of this product, first, the physical architecture diagram of the Project is shown as follows:

In this project, AdminSite and WebSite are placed in the FrontEnds folder. The two sites are the user front-end and the backend management front-end.

The WebApi, Service, and DomainMos (Models and Interface in the figure) class libraries are in the Layers folder to form the API basics.

As an Infrastructure class library, Infrastructure and Common (business-independent entity auxiliary class) can call

Repositories (this is currently the Mysql implementation of OSS. Core. RepDapper in the project, and may be supported by other databases in the future), mainly the specific implementation of Rep. Interface.

Plugs implements the log, cache, and configuration interface implementation under the Common plug-in. It can be called directly at all levels through Common.

Back to the microservice topic, in this product, I will not create a set of Class Libraries under Layers for each service. I will separate each service in this project through folder isolation, you can use WebApi as an API Gateway. The internal call sequence is as follows:

Code structure:

 

 

==================================

If you have other questions, follow the Public Account (OSSCoder)