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

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

Reference resources

https://microservices.io/index.html

https://blog.bitsrc.io/bff-pattern-backend-for-frontend-an-introduction-e4fa965128bf

Project address

https://github.com/zeromicro/go-zero

Welcome to use go-zero and star Support us ！

WeChat ac group

Focus on 『 Microservice practice 』 Official account and click Communication group Get community group QR code .

Microservice practice

Share the principles and best practices of microservices , Explain the underlying principles of service governance , Take you to read it carefully go-zero Source code .go-zero It's an integrated engineering practice web and rpc frame , Designed to shorten the distance from demand to online . The official account is wrong in the know number. ： Wan Junfeng Kevin

93 Original content

Official Account