Job content
Split the e-commerce system into microservices.
Background: Suppose you are the CTO of a start-up company now. The development team is about 30 people, including 5 front-ends and 25 back-ends. The back-end developers are all Java. Now you are going to start a small program e-commerce from 0 Business, please design the microservice split architecture and microservice infrastructure selection.
Require:
It is necessary to clarify the idea of service splitting, and draw a picture of the split system architecture;
It is necessary to clarify the selection of microservice infrastructure and choose a microservice framework;
Use 1~2 pages of PPT.
Answer
Split method - split by business
Since it starts from 0, choose to split by business.
Divide business boundaries
Regardless of whether there are business experts or not, the e-commerce system is a system with a relatively clear model, so directly refer to the industry's implementation as follows
! jpeg
Service splitting
According to the principle of three musketeers, an average of three developers are responsible for a microservice. Now there are 25 backends, then there can be a maximum of 25/3 = 8 microservices.
How to divide the 5 front ends? Because microservices are mainly located in the business layer of end-to-end layered services, and have little relationship with the user layer and presentation layer, the number of front-end developers is not considered here.
At present, ten business domains are divided, and two of them need to be merged. Because it is generally divided according to business, the subdomains belonging to the same large business domain are merged according to the similarity of business:
Combining items and shopping carts into one service;
Combining order and payment into one service, because order and payment usually need to be in one transaction, can reduce the complexity of the system. At the same time, due to the high internal complexity after the merger, four developers were assigned to be responsible for this service.
The final service division and system architecture are as follows
Implementation method
Because it starts from zero, it is chosen to be realized in one step.
Microservice infrastructure selection
Back-end developers all use the Java language;
Since it is a startup company with a small scale, and in order to avoid unnecessary maintenance costs, choose Spring Cloud or Dubbo;
Spring Cloud has wider applicability and more comprehensive components, so Spring Cloud is chosen as the microservice infrastructure.
Notes Part
Microservice Architecture Detailed Explanation
Microservice and SOA
The purpose of SOA is to connect the existing heterogeneous IT systems within the enterprise and reduce redundant construction. The means is to loosely couple the various systems together through the ESB. The result is bloated ESB logic, poor performance, and difficulty scaling. Smart pipes and dumb endpoints.
For microservices, in the words of Martine Fowler, the purpose is to split a large system into smaller services, communicate with each other through lightweight mechanisms, and emphasize that services can be deployed automatically. Smart endpoints and dumb pipes.
Regarding the connection between the two, there are several views as follows, but the last one is accurate, that is, there are many differences between them, but they are the same in terms of service orientation.
According to Mr. Qin Jinwei's explanation, the overall architecture of SOA and microservices is different
SOA/ESB: proxy invocation, direct enhancement
Distributed service: direct call, side enhancement
With the development of microservices, the microservice infrastructure has become powerful and complex.
Monolithic architecture, SOA, and microservice architecture are several different stages in the evolution of server-side architecture.
The relationship between microservices and other scalable architectures
Hua Tsai, like "DDD Practical Course", regards clean architecture as an architectural form for implementing microservices.
However, the perspective of "DDD Practical Course" is slightly different. The DDD four-tier architecture is also used as a specific form of microservices, and the layered architecture here is in a more general sense.
Relationship to layered architecture
A layered architecture is an end-to-end architecture or the internal architecture of a single system, which is divided into different levels according to certain rules. J2EE is also a kind of layered architecture.
Microservices are the architecture of the business layer in an end-to-end layered architecture:
In "DDD Practical Course", the layered architecture of DDD is directly given
And compare the three-tier architecture of the single backend service with the above four-tier architecture
Relationship to Clean Architecture
The architecture of a single microservice can be a clean architecture.
Relationship to microkernel architecture
The architecture of a single microservice can be a microkernel architecture, such as risk control, marketing, and workflow microservices.
"DDD Practical Course" also gives an architectural model available for microservices - hexagonal architecture (also known as "port adapter architecture")
Thinking questions
Compared with SOA architecture, what is the cost of microservices, or what are its disadvantages?
I think the cost of microservices is that the relationship between system nodes becomes very complicated. A business may pass through a lot of service nodes, and a mesh connection is formed between the nodes. But SOA is different, by introducing the ESB as an intermediate node, the mesh connection is changed into a "hub-spoke" type link.
This has led to more connections in the architecture, and more communication costs in the organization.
Microservice Architecture Traps and Challenges
Six Major Traps
I personally think that these traps are caused by the increased system complexity caused by the overall network connection of microservices.
granularity too fine
1. Complicated service relationship
It reduces the internal complexity of a single small service, but increases the external complexity of the connection between systems. Requirements analysis, solution design, testing, deployment... Difficulty will increase.
2. Decreased team efficiency
Requirements analysis, solution design, testing, deployment...the workload will increase. This is the impact on the organization.
3. It is difficult to locate the problem
The connectivity between nodes is too high, and the failure of a single node will cause problems for many nodes.
4. System performance decline
The longer the call chain, the longer the time-consuming for a single request. After splitting, the processing performance of a single service will be improved, which cannot make up for the consumption caused by the call chain. Because the main factor that determines the time consumption is the call of the storage system, after splitting into a single service, the improvement of a single service is limited; and the performance consumed on the call chain will exceed the performance improvement of a single service.
lack of infrastructure
5. Unable to deliver quickly
Without automated testing support, a large number of interfaces need to be tested for each test;
Without automatic deployment support, human operation and maintenance, hands are numb;
Without automatic monitoring, each fault location requires manual checking of various states and various log files of dozens of machines and hundreds of microservices.
6. Service management is chaotic
service route is required
need fault isolation
Requires service registration and discovery
For the above pitfalls, it is necessary to
suitable granularity
Perfect basic service
Four challenges of microservice architecture
Challenges brought by data distribution
1. Data is distributed on different service nodes, which will generate distributed things
Aggregation in microservices is the basic unit of data modification and persistence, and each aggregation corresponds to a warehouse to achieve data persistence;
If entities and value objects are understood as a database table or an object of a database table, then the aggregation is a database or a schema;
If the service is understood as rules plus data, then because the aggregation has a corresponding warehouse, the aggregation theoretically corresponds to a service.
Microservices and aggregation are not one-to-one, but one-to-many. Aggregation can be migrated between microservices as needed, for example, according to business needs, or according to quality attributes (migrate highly visited aggregations to independent microservices), or according to the degree of frequent changes Do separation (splitting frequently changed and infrequently changed services into different services).
Strong consistency of data within aggregation, and final consistency of data between aggregations;
The state of at most one aggregate can be changed in a transaction.
2. It is necessary to ensure global idempotence. Because distributed calls may fail and retry, idempotence needs to be guaranteed.
Challenges posed by service distribution
3. Interfaces need to be compatible
4. To solve the problems caused by the interface loop call
Responding to the four major challenges of
BASE, CAP, and linearizability
As mentioned above, the data in the aggregation is not strongly consistent, and the data between the aggregations adopts the final consistency model. There is a BASE theory about eventual consistency.
BASE:Basically Available (basically available), Soft State (soft state) and Eventually Consistent (final consistency). The eventual consistency is described by the CAP theory of distributed systems.
CAP consists of three properties: Consistency, Availability, and Partition tolerance. Among them, partition fault tolerance refers to a problem in the network, which divides the machines that were originally connected through the network into several independent parts, which is also called a split brain.
If you give up partition tolerance, then it is a stand-alone database, and it is impossible to give up P in a distributed system. Under the premise that partitions will occur, you need to choose one of consistency and availability, instead of combining the three properties in AP and CP. Choose one of three from CA and CA (CA is equivalent to a stand-alone database).
In addition, the C in CAP refers to the linearizability (Linearizability). In a distributed environment, there are not only consistency and inconsistency, but also other choices in the middle, such as whether it is objectively consistent or looks consistent.
State consistency refers to the consistency reflected in the objective and actual state of the data;
Operational consistency refers to the consistency of data that can be read by external users through operations agreed upon by the protocol. For example, various session consistency, that is, it looks consistent from the client.
Linear consistency/Linearizability
comes from "Distributed Financial Architecture Course".
The English name of linear consistency is Linearizability. Linear consistency is the most important consistency in distributed systems. It can be understood that linear consistency is Serializability in a distributed environment.
Serializable
Multiple transactions in the database can be executed concurrently, and serialization specifies the results of these concurrently running transactions, which requires that the final results of these concurrently executed transactions are always equal to the results of their sequential execution.
As above, after adjusting the execution order of transactions T1 and T2, there is no overlap in time between these two transactions. At this time, these two transactions are executed sequentially.
At the same time, after adjusting the execution order of transactions, the final read and write results are exactly the same as before the adjustment.
Finally, this adjustment result is not unique.
Conflict Serializability
"Conflict" refers to the three conflicts of reading and writing, reading and writing, and writing and writing. Conflicting serializability still requires the result of being equivalent to a transaction serializability. But it is not the same as serialization. Serialization only requires you to find an equivalent serial result, while conflict serialization requires you to change the original execution sequence through a series of conflict-free interchange processes. for equivalent serial execution.
If there is no conflict between the two operations, their order can be interchanged, also known as the non-conflict interchange process. There are two cases of non-conflict
The objects of the two operations are different
Both operations are read operations
An example is as follows:
In the implementation process of the database, the order of transaction execution is generally adjusted through locks, and the use of locks can generally achieve conflict serialization. The way to achieve serialization through locks is called 2PL (Two Phase Lock).
2PL（Two Phase Lock）
The process of 2PL is very simple. It requires that for any transaction, this transaction will first lock all accessed resources, then access all resources, and finally release all locks. The process of locking and unlocking cannot be alternated.
The change process of the number of locks in the 2PL process (the following is the most general process, and there are other variants, for example, see below, MySQL uses a variant), which means that locks are continuously acquired on demand until Operations can only be performed after all locks are held.
Conflict Serializability Using 2PL
The core principle is that the transaction that is locked first has a lock, and the subsequent transaction cannot write to the same resource without holding the lock, that is, there is no conflict between the two transactions, so they are naturally interchangeable Execution order, thus achieving conflict serializability.
Because there may be more than one lock held, more specifically: before the first transaction releases the first lock, it has no conflict with all operations of all other transactions, so it can be exchanged through conflict-free operations Procedure that advances all operations of the first transaction before other transactions. In this way, we can separate the first transaction from the remaining transactions.
2PL requires us to know ahead of time what all the data being accessed is, so we can lock everything before unlocking it. Once we release any lock, we can no longer add other locked resources, which is the limitation of 2PL.
But MySQL seems to have improved on the fact that it must be known in advance, and it locks on demand.
Two-stage lock in MySQL (the content is summarized from "45 Lectures of MySQL Actual Combat", "30 Lectures of Distributed Database")
Such as the following example
In the above figure, the update statement of transaction B will be blocked, because in the InnoDB transaction, the row lock is added when needed, but it is not released immediately when it is not needed, but is not released until the end of the transaction . It is also a two-phase lock protocol, or a variant-strict two-phase lock protocol (Strict 2PL, S2PL, that is, the transaction always holds all the write locks it has acquired until the transaction is terminated), as follows
Therefore, if multiple rows need to be locked in a transaction, the locks that are most likely to cause lock conflicts and affect concurrency should be put as far back as possible. For example, the business scenario of buying movie tickets:
-
Deduct the movie ticket price from Customer A's account balance;
-
Add the movie ticket price to theater B's account balance;
-
Keep a transaction log.
Imagine if there is another customer C who wants to buy a ticket in theater B at the same time, then the part of the conflict between these two transactions is statement 2. Because they want to update the balance of the same theater account, they need to modify the same row of data.
According to the two-phase lock protocol, no matter how you arrange the order of statements, the row locks required by all operations are released when the transaction is committed. Therefore, if you arrange statement 2 at the end, for example, in the order of 3, 1, 2, then the lock time of the theater account balance row will be the least. This minimizes lock waiting between transactions and improves concurrency.
linear consistency
Serialization is a stand-alone program that adjusts the execution order of multiple transactions, so that a reasonable order can be found, so that the results of sequential execution of concurrent transactions are consistent with the results specified by concurrent transactions.
And linear consistency is the environment of multiple programs, adjusting the start and end times of different program operations so that there is no time overlap between these operations.
Linear consistency also has a requirement for time adjustment, that is, if there is no time overlap between two operations, the time sequence between these two operations cannot be changed. At the same time, it is also required to verify the correctness of the adjusted results
strict serializability
The strongest consistency in the stand-alone case is serializability, and the most important consistency in the distributed case is linearizability. Then combine the two to get the strongest consistency in the distributed case, which is called strict serializability (Strict Serializability).
Serializable means that the execution results of all operations in two transactions are equivalent to a certain sequence execution result of these two transactions. There is no limitation on "a certain" here.
Strict serialization makes provisions for this "someone", which requires that the running results of two transactions are equivalent to the only sequential execution result. In this result, whoever's transaction ends first, then in the case of sequential execution, all operations of whoever ends first.
Although strict serialization has a strong correctness guarantee, its operating efficiency is extremely low, so it is generally rarely used.
Business-level distributed transactions - local transaction messages
The key is to put the writing business data and writing message data in the same local transaction to ensure that both succeed or fail, and then rely on the background thread to continuously retry to ensure that the message data is sent to another service and executed successfully.
In addition to writing business data, service A will also write message data to the table, and then a background thread will continuously read the message data and send it to service B, so that service B can modify the data; this background thread is in synchronization with MySQL master/slave/master-slave The dumpthread of the master node is very similar to
After service B receives the transaction message, it also executes writing business data and message data at the same time. The message data contains the result of executing the transaction message. Then send the transaction message processing response to the A service.
If "2. Transaction message" is lost, A service will keep retrying;
If "4. Processing Response" is lost, A service will keep retrying;
Service B receives the 2. transaction message repeatedly, and then checks whether the message table has been processed. If it has been processed, it will directly return the processing result, and if it has not been processed, it will be processed normally (idempotent).
Business-level distributed transactions - message queue transaction messages
It is very similar to local transaction messages, except that the messages are placed in the message queue. The operation of RocketMQ was given in Andy's class:
When sending a Prepared message, you will get the address of the message;
perform local transactions;
Modify the message status through the address obtained in 1;
RocketMQ will periodically scan the transaction messages in the message cluster. If it finds a Prepared message, it will confirm to the message sender, and RocketMQ will decide whether to roll back or continue to send confirmation messages according to the policy set by the sender.
The more general principle is as follows. (Quoted from the fourth lecture of "Message Queue Master Course": "How to use transaction messages to implement distributed transactions?")
The essence is the same as the "local transaction message", which also guarantees that the execution of local transactions and the successful sending of transaction messages will either succeed or fail. The difference is that the "local transaction message" is resolved by retrying, and the message queue is implemented by relying on the **"read committed" isolation level (this is summarized by myself, which is not written in the original text), and the message queue carries The "read committed" isolation level is half-message**.
A half message does not mean that the content of the message is incomplete, it contains the complete content of the message. The only difference between a half message and a normal message is that the message is invisible to consumers before the transaction is committed.
If the order is successfully created, submit the transaction message, and the shopping cart system can consume this message to continue the subsequent process.
If the order creation fails, the transaction message is rolled back and the shopping cart system does not receive the message.
In this way, the consistency requirement of "either all succeed or both fail" is basically realized.
What if there is a failure in committing the transaction message in the fourth step?
Kafka's solution is relatively simple and rude, throwing an exception directly and letting the user handle it by themselves. We can retry the submission repeatedly in the business code until the submission is successful, or delete the previously created order to compensate.
In the transaction implementation in RocketMQ, a transaction reverse check mechanism is added to solve the problem of transaction message submission failure. If the Producer is the order system, and a network exception occurs when the transaction message is submitted or rolled back, and the Broker of RocketMQ does not receive the request for submission or rollback, the Broker will regularly check the status of the local transaction corresponding to the transaction on the Producer, and then According to the results of the reverse check, it is decided to commit or roll back the transaction.
In order to support this transaction anti-check mechanism, our business code needs to implement an interface for anti-check local transaction status to inform RocketMQ whether the local transaction is successful or failed. RocketMQ will automatically commit or roll back the transaction message according to the result of the transaction reverse check.
Business-level distributed transactions - TCC
mainly records the following points:
It is allowed to cancel a non-existent transaction, also called empty rollback. At this time, the Try method has not received a timeout due to network problems, and the transaction manager will issue a Cancel command at this time, so it needs to support Cancel to be able to cancel normally without executing the Try.
Anti-hanging. The Try method triggers the transaction manager to issue the Cancel command due to network congestion timeout, but after the Cancel command is executed, the Try request arrives. Obviously, the Try command should not be executed at this time. How do you know whether it should be executed? See next item.
Cancel is followed by Try. For the transaction manager, the transaction is over at this time, and the Cancel operation is "suspended". Therefore, an empty rollback needs to leave a record in the system to prevent the re-invocation of Try.
There are several variants of TCC:
Standard TCC
TCC without try
Asynchronous TCC
Asynchronous TCC is very similar to local transaction messages and message queue transaction messages. During Try, messages are only written and cannot be consumed. Confirm is the operation of actually sending messages, and Cancel is to cancel the sending of messages. This is a half-message.
Global idempotence Global
idempotence ensures that each idempotent operation is globally unique.
design key
globally unique ID
state machine
Interface Compatibility
Some interfaces of a microservice are upgraded, and microservices that depend on these interfaces may not all be upgraded at the same time.
Solution:
There are multiple versions of the interface, directly copy an old interface code, modify it on the old interface code, and add v1/v2 to the interface URL;
This also has something to do with the organizational structure. In the current company, the core interface upgrade is to force all dependent systems to be upgraded.
Andy specifically emphasized that copying the code at this time is not a DRY principle. because of this:
Does not affect existing functionality;
It is more convenient when the old interface is offline, and unnecessary testing can be avoided.
The interface logic is compatible, the same interface code is compatible with the old and new logic, and it is easy to affect each other, and the code needs to be modified when the old interface is offline (not recommended).
Interface cyclic call
For example, during a business process, A calls B, and B calls A again, and the processing of A enters the previous processing logic, resulting in cyclic calls, and the entire business enters an endless loop.
Solution: There are almost no good solutions. If you are lucky, you can find it by testing. If you are not lucky, you can find it by going online.
Thinking questions
Recall what pitfalls and technical challenges you have encountered in the course at work, and think about what are the main reasons?
Too bad, the company's micro-service has just begun...
Microservice infrastructure selection
Microservice infrastructure and its priority
There are 20 modules in total, and the classification diagram is as follows. The green box is the core of the microservice framework.
Microservice framework (core) mode
Embedded SDK mode
Such as Dubbo and Spring Cloud.
reverse proxy
Such as APISIX.
Network proxy (Service Mesh)
Such as Istio.
It can be seen that the commonality between the service grid and Spring Cloud or Dubbo is that there is a relatively large overlap in service registration, service discovery and service routing. So they are compared together.
Each mode is not recorded separately, directly record the comparison chart
How to choose an open source microservice framework
Thinking questions
Since the infrastructure of microservices is more complicated than ESB, what is the need for microservices?
Because microservices have been developed and Internet technology has penetrated into traditional industries, it is impossible to go back and engage in SOA again.
Microservice splitting skills
Three elements related to
the skill Splitting method
Infrastructure
Implementation method
Implementation suggestions
The above table can conclude that the splitting of microservices also follows the three principles of architecture - the principle of appropriateness, the principle of evolution, and the principle of simplicity. At the same time, it also solves the complexity of the architecture first, and then improves the quality of the architecture:
That is, the splitting of microservices also requires the pursuit of correctness first, and then the pursuit of optimization
If it is a new microservice (including building a business system from 0 and transforming a single microservice), it should be split according to the business, because the service itself is a business concept, which is carried out under the guidance of DDD, and DDD is exactly Start with business. (principle of suitability)
If it is to optimize microservices, it can be split according to quality (evolutionary principle)
infrastructure is a must
When creating a new microservice, new infrastructure needs to be built, but the infrastructure also has priorities, and it must be gradually implemented according to the priorities (simple principle, evolutionary principle)
When optimizing microservices, reuse existing infrastructure (principle of fit)
There are two ways to implement services (principle of suitability, principle of evolution)
complete in one step
The one-step approach is adopted when building a new building.
step by step
Especially when transforming a single architecture, start with non-core business modules
Detailed explanation of the splitting method
Splitting microservices according to business
Difficulties in DDD
Theoretically, DDD methodology should be used for guidance.
But DDD is difficult to implement because:
The determination of the division of the bounded context depends on the influence of business experts.
The bounded context is actually the "boundary of the team"
Bounded contexts are also affected by team conditions such as team size
To sum up, it is more affected by organizational form.
The actual business boundary division process
The actual division process is not DDD, but as follows:
Note that it must be roughly divided first and then evolved, not subdivided first and then merged. Because of the latter:
First of all, the workload will be very large: in order to ensure the correct and efficient operation of the microservice business, a large amount of infrastructure is required.
Secondly, the merger itself is more difficult than the gradual split.
The corresponding relationship between the actual business domain and the service - the concept of service splitting
DDD, there are the following concepts from bottom to top, from small to large:
Entity (the entity class of the hyperemia model, an entity may correspond to 0, 1 or more database persistent objects, the ability to realize individual business), value object (the class corresponding to the anemia object)
polymerization. Entities and value objects make up aggregates. Business logic across multiple entities is implemented through domain services, which sit on aggregates.
Aggregation is the basic unit of data modification and persistence. Each aggregation corresponds to a warehouse to achieve data persistence: if entities and value objects are understood as a database table or an object of a database table, then the aggregation is a database or a schema.
If the service is understood as rules plus data, then because the aggregation has a corresponding warehouse, the aggregation theoretically corresponds to a service, but the microservice and the aggregation are not in a one-to-one form, but there are multiple relationships, that is, a microservice Multiple aggregations can be contained within. Therefore, there are several types of correspondence between business domains and services. They actually describe the granularity of microservice splitting, and the size of the granularity must follow the principle of appropriateness—it must be suitable for the current situation of the team. See "The Three Musketeers Case" ".
One-to-one: each business domain corresponds to a microservice
Many-to-one: multiple business domains are handled by one microservice
One-to-many: splitting of business processes, listing the processing flow of core business functions, and taking the processing steps in the process as the dimension of splitting.
In addition, aggregation also has context boundaries, and the domain model can guide the design of microservices upwards by using the bounded context, and the design of aggregate roots, entities, and value objects can be guided downwards through aggregation.
Finally, the data within the aggregation is strongly consistent, and the data between the aggregations is eventually consistent.
The above description can be summed up with Hua Tsai’s picture:
The Three Musketeers Principle
Definition: An average of 3 developers are responsible for a microservice.
Why not alone?
Because there is no backup for personnel, and one person's thinking is limited.
Why not 2?
2 people are responsible for maintaining a microservice, and the complexity of the microservice is low. Not conducive to personal professional growth!
Why not 4 or 5?
If there are 4 or more, everyone may not be able to grasp all the details of a single service.
Number of microservices = number of developers on the server side/3;
For services in the maintenance period, there can be 2 maintenance personnel.
The case of the three musketeers
Splitting microservices by quality
means migrating and merging aggregates between microservices as needed.
Split according to performance
Split the business with the largest traffic and the business with strong correlation to reduce the degree of business mutual influence, optimize the business with large traffic after splitting, improve performance and reduce costs.
Split according to the importance of the business
Separate the business with high importance (not necessarily high traffic) to reduce the mutual influence of the business, and improve the availability of the high-importance business after the split.
Split according to availability
Split out the business that often has problems to reduce the degree of business interaction, and after the split, improve the business with many problems in a targeted manner.
Split according to stability
Split out stable businesses to reduce the degree of mutual influence between businesses. After splitting, it is conducive to rapid iteration of ever-changing businesses.
Thinking questions
When splitting microservices according to quality attributes, do we need to follow the three musketeers principle?
It still needs to be followed. Because the object of splitting at this time is still various business services, and the construction of business services should follow the three musketeers.
In-depth analysis and implementation skills
of the middle platform The emergence of the middle platform is to deal with business complexity.
The development process of the shared architecture
There is no shared architecture, "there are many chimneys", and they are developed repeatedly;
Shared resources - Iaas architecture;
Shared Runtime, middleware, DB, etc.
SaaS, the entire application is shared.
Middle-end structure. Different from IaaS, PaaS and SaaS, it shares the same business and data in each business.
Understanding the concept of Zhongtai
Hua Tsai pointed out that there are two types of Zhongtai - business Zhongtai and data Zhongtai.
Business middle
platform Business middle platform is an architectural model that deposits the general business capabilities of multiple similar businesses in an enterprise onto the platform to reduce redundant construction and improve business development efficiency. Three key points:
business related. This distinguishes middle office from IaaS, PaaS from SaaS.
across multiple businesses.
Multiple businesses are similar. Therefore, businesses that are too different cannot be forced into the middle office.
Data center
Data center is an architectural model that deposits all business data of an enterprise on the same platform, supports data connection and data reuse between businesses, and improves enterprise operating efficiency. The three key points are as follows
all business. The data center should support all businesses.
The data is connected. Data between businesses needs to be connected.
Data reuse. Data between different businesses can be reused to improve overall operational efficiency. The most difficult part of the three, because the data is distributed in different businesses, the difference is relatively large, and it is difficult to reuse across businesses.
The value of the middle platform
Business middle platform. Its value lies in that similar businesses can leverage each other and share capabilities, thereby avoiding a large number of repeated development and improving development efficiency. Therefore, the higher the business similarity, the greater the value of Taiwan in the business. Hua Tsai suggested that multiple businesses with a similarity of more than 60% jointly build a middle office.
Data center. Its value lies in data connection and reuse, avoiding data islands and improving operational efficiency.
The more businesses that use the data center, the greater the value of the data center.
The value of the data center is reflected in: unified data platform, cross-business data connection, and cross-business data reuse (mining).
But data reuse across businesses is difficult. Data analysis is a process of discovering and extracting rules, and the differences between businesses are quite large. How to set the goal of data reuse is a difficult goal in itself. For example, two business departments have different business languages and thinking modes, how to extract the correlation of data? Communication is a big problem.
The problem brought by the middle platform
Small business embraces the thigh of the middle stage, and the middle stage embraces the thigh of the big business. The construction of the middle stage is finally an organizational structure problem; for this point, there is no good way to deal with it. The construction of the middle stage is ultimately a problem. Organizational Structural Issues (Conway's Law).
The boundary between China and Taiwan is difficult to clarify. That is to determine which businesses are implemented by the middle office and which businesses are implemented by themselves, and the boundaries are not clear. The most difficult part of the middle office design is not the domain division, but the boundary division between the middle office and the business! China and Taiwan are suitable for "combined innovation", but not "subversive innovation". It can be alleviated to a certain extent by using Pipeline to encapsulate different business processes.
The efficiency of the whole process in the middle office is not high. The essential reason is that in terms of organizational structure, the business corresponds to different departments, and the cost of cross-departmental communication can be imagined to be relatively large.
Boundaries are discussed for each business function;
Each business function has to consider the impact on all businesses.
It can be alleviated to a certain extent by using Pipeline to encapsulate different business processes.
Middle-end landing skills
Use microservices to build middle-end. As the saying goes, "Microservices are not necessarily Zhongtai, Zhongtai must be microservices!".
Use Pipeline to encapsulate different business processes, so as to alleviate the problems of difficult boundary division between middle office and business, and low efficiency of the whole process.
Pipeline similar to Netty uses Handler to encapsulate different function points in different processing flows. It is equivalent to the chain of responsibility pattern in the design pattern, corresponding to the composition in object-oriented.
Different services are encapsulated with SPI. It is equivalent to the template pattern in the design pattern, corresponding to the inheritance in object-oriented.
Comparison of Pipeline and SPI solutions
According to the view that composition is preferred over inheritance in design patterns, it seems that Pipiline should be used first. In fact, Hua Tsai also said that it should be used first
Pipiline, the main reason is that its development difficulty is low, while SPI needs to clarify the boundaries between the middle platform and business, and the development difficulty is high
Thinking questions
If the company already has a business that is running online, and now plans to do a similar business, do you need to go to the middle office at this time?
According to the situation, because the more similar businesses in the business, the higher the value, and at this time there are only two similar businesses. According to the principle of suitability, if there are not many such cases, there is no need to go to the middle platform; if the business development is very fast Fast, you can consider making a simple middle platform, follow the principle of first coarse-grained and then split.
Practical Combat - Microservices for mobile game e-commerce platforms
If the existing architecture is monolithic, microservice transformation is not necessarily the best and natural answer to solve the problems of the existing architecture, and specific problems need to be analyzed in detail.
Thinking questions
What are the advantages and disadvantages of the highly abstract business model in the business?
Advantages: can be reused. The requirements for design are relatively high. If the design is not good, the reusability is not good.
Disadvantages: It cannot be directly used for specific businesses, requires further development, and the communication cost is relatively high.