Oss. Core Basic Ideas

Now the framework of two words has been Rotten Street, XX company structure design everywhere, but mostly to see a lively, how these frameworks, details and how to think, the isolation between the basis is what ... Believe that many friends should still have their doubts, especially the increasingly hot micro-services and derivative services Gateway products, Just recently intends to write a small open source framework Oss.core, the process of a little thought, through this article record, but also hope to try to help everyone to understand, probably around the following several questions:

1. Origin of micro-service generation

2. Micro-Service Design ideas

3. OSS. Design and implementation of core framework

Before I start, I want you to understand that the traditional architecture and the microservices architecture are not independent/antagonistic, and microservices are the logical concepts derived from the traditional framework to deal with the problems of concurrency maintenance, and more so in the different stages of the project to think about and solve the problem. Second, the logical and physical schemas (files) are distinguished, and most of the time the logical and physical architectures correspond, but sometimes a physical schema can contain multiple logical schemas.

I. Origin of micro-service generation

Micro-service is mainly to be a number of large, complex applications to split into multiple service portfolio, each service autonomy, to achieve more flexible, easy to maintain the effect.

To get a better understanding, let's look at three common ways to solve concurrency:

1. Add the database master-slave separation, or even multi-master write or partition mechanism, in the application corresponding to modify the connection string or add access middleware, to improve the database processing capacity.

2. Due to the relatively tight database resources and time-consuming, in order to improve the speed of access, this time generally also through the distributed cache and so on to reduce the access to the underlying.

3. Load-balanced offload processing, which is distributed to different machines before a large number of requests reach the application, to solve the single-machine bandwidth and performance bottleneck problem.

Of course there are many other ways to solve concurrency, such as front-end static file compression, CDN acceleration, IP rate control, and so on, first skipped.

Above these three methods many friends should have seen, the reason is listed here, and then combined with this diagram can be more easily compared to the traditional whole service to the change between the service:

In the traditional overall service framework, there is a great coupling between the modules, there are mutual calls within the project, and a variety of complex aggregation operations, so in most cases can only be deployed as a whole, in the diagram on the left we can see that load balancing we need to be deployed on more than one machine, relative to the database is also the case, And the requirements for each module in a project are different.

For example, the frequency of access and the complexity of the process of the product and the next single module is very different, the next single frequency is relatively small, the complexity is high, we would like to run in a relatively small budget capacity of the machine, but also facilitate faster troubleshooting and maintenance. As you can see in the image on the right, after the service is refined, we can use a smaller deployment unit to combine the situation.

At the same time, in the rapid iteration of Internet products today, a product needs to have a fast for different end-line different application capabilities, while the adjustment of the business can be quickly on-line, the traditional overall service model has been inadequate. MicroServices have been piecemeal, but because each module's independence can quickly be combined, and each module can be based on different demand points of different characteristics of the programming language.

　　

Two. Micro-service Design ideas

Because each product has its own standards and focus, so the design of service units are different, but there is a basic point: service autonomy

When you design a micro-service module, you need to ensure that the current service independence, especially the independence of the data module, other services do not have the right to directly manipulate the database module under the current service, external interaction can only be done through the service interface. Because the modules are independent, you can choose the appropriate programming language, and the corresponding size of the deployment. To achieve local flexible optimization. While microservices are independent of each other, it also brings some of the problems we need to face:

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

Since the service unit is to be minimized, it is necessary to determine the responsibility boundary of the service, which is a combination of the following: service lifecycle Processes , areas , and estimated scale , such as User Services, In the small number of visitors can be the user base information, balance accounts in a service module, to reduce the amount of work to reduce energy dispersion. Large-scale, and then sub-basic services and asset services.

　　Second: cross-service data query problems

For example, in the client search for goods, you can also search users or statistical data query how to deal with. For this I give two ways of handling:

1. API Gateway

This situation is suitable for too many service units, the client needs to query the use of different service unit data, this time we can build a targeted API Service Gateway (note and the App Gateway Division), through this gateway aggregation of multiple services, the client only need to interact with the current gateway, Gateway aggregation is forwarded to different microservices. Such as:

2. Data redundancy or background data synchronization

For example, in the order information I need the user's name and so on a small number of user fields, this time can completely redundant these fields to the order micro-service data module. Another example in the statistical module, its data manufacturers and respondents completely belong to different objects, no very high real-time, I suggest to create a statistical service and the corresponding statistical database, the other services through the event message interaction, update the corresponding statistics, query through the statistical services of their own data can be completed.

　again: How to solve the communication problem between services

Because we have separated the services from each other, we sever the possibility of directly manipulating different service databases. So the consistency of the data is handled, and in the traditional service model because it is all mixed together, we can guarantee the consistency of the data through the transaction or the stored procedure. There are two common ways to do this:

1. Asynchronous event message-driven

This type of solution is suitable for scenarios where the real-time requirements of data are relatively low, such as statistical service updates on the top, message notifications for a message queue push response after an event triggered by a service such as an order, and the service that subscribes to this queue receives updated data.

2. Direct interface Request (HTTP,RPC)

In general, it is not recommended to prevent cascading dependencies from happening. This type of data is mainly for the real-time requirements of high demand, such as in seconds to kill the order process need to immediately know the success of the inventory service deduction. (Note: Support for task under. NET is particularly good, HTTP requests are recommended to use async, while the front end returns TASK<ACTIONRESULT>, reducing worker thread consumption due to IO operations)

　　finally: how the client accesses

When we encapsulate the service, how the service and the last client access, this needs to be based on the actual security rules and requirements of each decision, in general, if the service is relatively small, the function is not complicated can directly expose the service interface to the client access,

Or it can be provided to the client via the API gateway above, but there are also many mature microservices gateways such as service fabric or API Management on the Azure cloud.

Three. OSS. The idea and implementation of core framework

Oss. Core This project is a small open source product that I wrote recently, knowing that my friends should know I wrote some components like: OSS. Social,oss. Paycenter,oss.common,oss. Http this project would like to be able to put these components in series, the above has introduced the approximate way of micro-services, I will be in the logical framework of this product as much as possible to reflect this, first of all the project's physical structure diagram to show:

This project Adminsite,website placed in the Frontends folder, the two sites are the user front-end, and the background management front-end

Webapi,service,domainmos (Models and interface) class libraries in the Layers folder form the base of the API

Infrastructure (Business-related generic Entity enumeration helper classes) and Common (business-Independent related entity helper classes) as infrastructure class libraries, can be called in class libraries at all levels

Repositories (temporarily the MySQL implementation of OSS.Core.RepDapper in the project, which may add additional database support later), is mainly the rep: interface specific implementation.

Plugs is implemented by the common plug-in log, cache, and configuration interface specifically implemented, can be called directly through common at all levels.

Back to the topic of microservices, in this product I will not create a set of layers for each service class library implementation, I will be in this project through the form of folder isolation to separate services, you can use Webapi as an API Gateway, internal call order I hope this:

Now the code structure diagram: