当前位置：网站首页>Go zero micro Service Practice Series (II. Service splitting)

Go zero micro Service Practice Series (II. Service splitting)

2022-06-10 00:22:00 【pythonxxoo】

High quality resource sharing

Learning route guidance （ Click unlock ）	Knowledge orientation	Crowd positioning
🧡 Python Actual wechat ordering applet 🧡	Progressive class	This course is python flask+ Perfect combination of wechat applet , From the deployment of Tencent to the launch of the project , Create a full stack ordering system .
Python Quantitative trading practice	beginner	Take you hand in hand to create an easy to expand 、 More secure 、 More efficient quantitative trading system

Overview of microservices

Microservice architecture is an architectural style , It builds a large system into a collection of multiple microservices , These microservices are built around business functions , Services focus on a single business function , These services have the following characteristics ：

Highly maintainable and testable
Loose coupling
Independently deployable
Build around business functions
Maintained by different small teams

The microservice architecture can 、 frequent 、 Reliable delivery of large 、 Complex applications , Realize service componentization through business splitting , Use components for composition to quickly develop systems .

Division of services

Let's first divide the microservices , In actual project development , We usually adopt two micro service partition strategies , The first method is to divide the boundaries of microservices through business functions , The second way is through DDD The boundary context is used to divide the microservice boundary , Here, we use the business functions that are easy to understand to divide microservices , Once again, post the mind map of our e-commerce project ：

From the above mind map, we can see that the whole e-commerce system has many functions , We divide the following micro services according to business functions ：

Goods and services (product) - Addition of goods 、 Information Service 、 Inventory management and other functions
Shopping cart service (cart) - Add, delete, modify and check the shopping cart
Order service (order) - Generate order , Order management
Payment services (pay) - The payment function is realized by calling the third-party payment
Account Services (user) - User information 、 Grade 、 Prohibition 、 Address management
Recommended services (recommend) - Home page product recommendation
Comment service (reply) - The comment function of the product 、 Comment reply function

BFF layer

Generally, we will use... For the client HTTP Interface to provide services , Does it mean that these micro services need to be provided directly HTTP The interface provides external services ？ Of course you can , The architecture as a whole looks simple .

But for a complex and highly concurrent system , We need to deal with various exception scenarios , For example, a page needs to rely on data provided by multiple microservices , In order to avoid the time-consuming caused by serial requests , We usually request multiple microservices in parallel , At this time, if a service request is abnormal, we may need to do some special processing , For example, provide some degraded data . In addition, the data displayed on our pages are often business function oriented , Not just the data of a microservice , At this time, we often need to assemble the data of multiple microservices to meet the requirements , If each of our microservices is directly provided externally HTTP Interface , Then these complex data assembly and exception handling can only be completed by the client . As we all know, the client is not suitable for complex business logic , The client should focus more on the optimization of interactive experience , Our overall architecture needs to be light in the front and heavy in the back , That is, the client logic should be as few as possible and the heavier business processing logic should be sunk to the server , The server is divided into different microservices according to business functions , These microservices focus on a single business , So where should these complex logic processing for business scenarios be put ？ Our solution is to add a layer , namely BFF layer , adopt BFF External provision HTTP Interface , Client only with BFF Interact .

BFF The introduction of layer solves the problems we encountered above , But adding one layer will increase the complexity of the architecture , So if your service is a single application , that BFF It's not necessary , Introducing it doesn't add any value . For our project , Our applications depend on microservices , At the same time, we need to provide business oriented functions HTTP Interface and ensure high availability of the interface , therefore BFF It is a suitable choice for our project .

We can provide multiple BFF Do you ？ The answer is, of course .BFF The purpose of is to provide a centralized interface for the client , For example, the data protocols of mobile terminal pages and browser pages are different , In this case, in order to better represent the data , Two can be used BFF, Only one at the same time BFF If it's time to BFF Exceptions will affect all businesses , Provide multiple BFF It can also improve the availability of services , Reduce the impact of business exceptions . Multiple BFF The architecture is as follows ：

In order to simplify our project, only one BFF service .

Engineering structure

We use centralized management , Put all the services in one big warehouse , The directory structure of the warehouse is as follows ：

lebron For the name of the project ,lebron There is apps and pkg Two directories , among apps All our micro services are stored , such as order For order related microservices ,pkg The directory is the storage path of packages that all services depend on , For example, if all services need to rely on authentication, they can be put into pkg Under the table of contents .

app - BFF service
cart - Shopping cart service
order - Order service
pay - Payment services
product - Goods and services
recommend - Recommended services
reply - Comment service
user - Account Services

Under each service directory, we will divide it into multiple services , There are mainly the following types of services ：

api - External BFF service , Accept requests from clients , expose HTTP Interface
rpc - Internal micro Services , Only accept other internal micro services or BFF Request , expose gRPC Interface
rmq - Responsible for flow task processing , Upstream typically relies on message queues , such as kafka etc.
admin - It is also an internal service , The difference in rpc, Most of them are oriented to the operation side and have high data authority , Isolation can lead to better code level security , Provide directly HTTP Interface

apps The structure of each service under the directory is as follows ：

Most services are split into rpc、rmq and admin To meet the demand of providing rpc Interface and operational data requirements , At the same time through rmq To handle streaming tasks . What's more special is app There is only api service , because app yes BFF All but api service , It may be added later rmq service , For example, stream processing users' first login and experience every day , We can expand at any time later , For the time being, only api service .recommend Only rpc service , Because the recommendation service needs to rely on AI Data provided by the team or big data team , We only need to request the corresponding data interface and do some business processing , So here recommend Only rpc service .

Code initialization

The structure of the whole project has been clearly defined , Let's initialize the service code

We use goctl To initialize the project , For example, let's initialize order, Enter the first order Under the table of contents ：

$ cd lebron/apps/order

Execute the following command to initialize order rpc Code

$ goctl rpc new rpc

The generated code structure is as follows ：

Execute the following command to initialize order admin Code , Be careful order admin by api service , Directly to the front end HTTP Interface

$ goctl api new admin

The generated code structure is as follows ：

The generated service code can be run directly , Default listening is on 8888 port

$ go run admin.go

Starting server at 0.0.0.0:8888...

about rmq Service we will use go-zero Provided kq function , Here, first initialize main.go

Come here order The code initialization of the service has been completed , Other services and order The service is similar to , I won't go into that here .

pkg There is no need to initialize , When we need to provide general business functions, we add them .

Conclusion

In this article, we explained the definition of microservices , Microservices are built around business functions , Services focus on a single business , Lightweight communication mechanism is adopted between services , Each microservice can be deployed and tested independently .

We split the microservices according to the functions of the mall , Mainly split the shopping cart 、 Order 、 payment 、 goods 、 Comment on 、 recommend 、 Account number and other services , Then we explain why we need to introduce BFF service ,BFF It is essentially a service for data assembly , Provide business oriented or client oriented services externally UI Of HTTP Interface .

Then we define the directory structure of our project , It is mainly divided into api、rpc、rmq and admin Etc , Different services have different responsibilities ,api External provision HTTP Interface ,rpc Provide internally RPC Interface ,rmq Do streaming data processing ,admin Provide for the operation background HTTP Interface .

Finally, we passed goctl Initialize the project , Use goctl Project framework code can be generated with one click , Great productivity .

I hope this article can help you , thank you .

Every Monday 、 Thursday update

Code warehouse ：https://github.com/zhoushuguang/lebron