This paper discusses:

  • What are microservices
  • Constraints on microservices
  • The impact of microservices on architectural properties

What are microservices

A microservice is an architectural style, that is, a microservice is a set of architectural constraints.

REST is a composite architectural style, and so is microservices! Microservices are much more restrictive, and it constrains both the development process and the developer!

Constraints on microservices

In his article Microservices, MartinFlower elaborates on the constraints that Microservices need to have!

  • Componentization via Services: service-based Componentization

  • They are Organized around Business Capabilities

  • Products are not Projects

  • Smart Endpoints and dumb Pipes: Smart endpoints and dumb Pipes

  • Decentralized Governance: Decentralized Governance

  • Decentralized Data Management: Decentralized Data Management

  • Infrastructure Automation: Automation of Infrastructure

  • Design for Failure: Fault tolerant Design

  • Evolutionary Design: Evolutionary Design

In fact, these constraints answer several architectural concerns:

  • How is the system segmented: organized around business capabilities, decentralized data management
  • How do modules communicate with each other: service-based componentization, intelligent terminals and silent pipelines
  • How to select technology: decentralized governance
  • Fault tolerance: Fault tolerance design
  • Scalability: Products not projects, evolutionary design
  • Maintainability: Infrastructure automation

The following instructions one by one!

How does the system slice?

At the end of “Architectural Style: Cure-all CS versus Layering,” I mentioned that in general, when you don’t know which architecture is best for a system, use layering first. Layered architecture is the partitioning of a system layer by layer, with the lower layer providing services to the upper layer.

What are the boundaries of each layer? It’s “system functionality”! Presentation, business logic, data storage. You’ll find that this shard has nothing to do with the business itself, so it’s a cure-all!

In addition, this sharding method divides developers into front end, back end, DBA! This is the current mainstream practice, it seems that there is no big problem!

If you’ve ever worked in a large company, you know how difficult it can be to make a requirement change. Even a simple requirement may require the participation of all teams.

What are the causes of this problem? It’s the communication cost!

The complexity of the project management algorithm is O (N 2). As more and more people become involved, the communication cost increases exponentially:

  • In a team of 5, the communication channel is 5*(5-1)/2 = 10
  • For a team of 15 people, the communication channels required are 15*(15 — 1)/2 = 105
  • For a team of 50 people, the communication channels required are 50*(50 — 1)/2 = 1,225
  • For a team of 150 people, the channels for communication are 150*(150-1)/2 = 11,175

We all know that “technology is for business”! If an architecture is irrelevant to the business, how can it serve the business? If communication takes a lot of time, how do you move the project forward quickly?

So, microservices are “organized around business capabilities”!

  • It involves systematic segmentation
  • It also includes the organization of people

Because Conway’s Law says:

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” – Melvin Conway (1967).

In microservices, each module (the module here is somewhat different from the module we usually understand, and its granularity is larger, so it is generally called a service in microservices, the use of “service” below) is a complete business system! This includes presentation, business logic, and data storage! Accordingly, the person responsible for development needs to have all the skills needed to develop the service!

That is, in microservices the boundaries of the service are the boundaries of the business!

This is similar to Hando Ishel s IOSSP, which focuses on product teams. Divide the enterprise into “small collectives”, like “amoebas”, which are free to repeat and split. Each amoeba is the core, making its own plans, accounting independently and growing continuously. Take a product team of three: a designer, a page creator, and an inventory manager. These three are responsible for page creation, style design, size estimation and inventory depth estimation for a single item.

In microservices, two or three people are responsible for a service, which contains a complete business process, and developers need to master the complete skills needed to develop the service, including UI, programming, DBA!

The difficulty here is:

  • One is to delineate business boundaries so that each service is highly cohesive and low coupled!
  • The second is to establish norms conducive to the communication between services
  • Third, the requirements of personnel skills are higher

How to divide services depends on specific services. I’m not going to expand it here. Just one thing, take transactions into account!

That is to say, when shard the system, consider transactions! We all know that remote transactions are a tough problem to deal with! Neither two-phase commit nor three-phase commit is a good solution to the distributed transaction problem! Paxos algorithm is too complex and has poor performance.

So the suggestions for microservices are:

  • Try to ensure that transactions are executed within a service
  • The problem of transaction operation is compensated by way of compensation

How do services communicate?

For normal systems, we all use in-process communication, which means we communicate by calling methods in the same memory! Common code can be organized in the form of “libraries” to avoid code duplication! This kind of system is commonly called “monomer system”!

The scale of “monolithic systems” is not ideal! For example, double 11 needs to do an activity, instantly the number of users increased! If you need to handle peak traffic, you need to expand your system. But because it is a single system, expansion can only be expanded as a whole, and in fact, only the active page needs to be expanded! This leads to a waste of resources. Another problem is that if this activity causes the system to crash, it will disable all functions of the system!

One solution is to “servize”! That is, the common logic of multiple systems or modules with high TPS are required to be deployed independently to make service calls through inter-process communication. For example, when the active module provides external services as a service and needs to be expanded, only the active service needs to be expanded. At the same time, if the activity service has a problem, only the activity related content can not be accessed, and does not affect other functions of the system. Taobao’s address service was suspended on November 11 this year, but it did not affect taobao’s own access.

By “servitization” I mean servitization using a servitization framework like Dubbo, not SOA using an ESB!

Esb-based SOA is primarily about connecting systems across the enterprise! The ESB acts as a “smart” pipeline to connect “dumb” nodes. To integrate services across different systems and protocols, an ESB does a number of things:

  • Message routing
  • choreography
  • conversion
  • Business processing rules

This makes the ESB heavy and complex. This is one of the reasons esB-based SOA has been criticized.

Servitization frameworks like Dubbo address runtime code reuse, system scalability, and high performance! But the service granularity is relatively small, the problem is that the maintenance cost is relatively high!

Microservices, on the other hand, does a bit of a compromise:

  • Services are more granular and contain the presentation, logic, and storage of a complete business. Relative quantity is less than servitization, maintenance is relatively easy
  • Services are provided in the form of interprocess communication. Including external services, as well as other services. Scalability is ensured.
  • The business logic processing takes place inside the service, and the communication component only provides the pure communication function. Simplicity is guaranteed.

This eliminates the onerous ESB and reduces maintenance!

How to select the technology?

For “how to choose the technology”, microservices are not mandatory development platform! Because “there is no silver bullet”! Microservices tend to be “the right tool for the right problem”!

Every programmer has his own favorite technology system! Some like Java, some like it. Net, C++, Lisp…

So what kind of technology architecture do you choose to develop the system? The point of view of microservices is: use whatever technology is right for you! This service requires high concurrency and can be developed with Go! This service needs to be advanced quickly and can be done in PHP! This service needs to be stable and can be used in Java! It looks perfect!

In fact, this leads to uncontrollable! Why is the Java language used by many enterprises? One reason is control!

For example, the technology stack of domestic companies is relatively simple! For example, the company’s main language is Java,.NET,PHP, etc., other languages are just auxiliary! There aren’t usually two, or even three, dominant languages!

Suppose a company’s dominant language is Java! It may take 10 people to develop a system. That company can recruit 5 or 6 average, 2 or 3 good, 1 awesome! All the company has to do is hold on to that jackass! If someone leaves, someone else just takes over!

And if each service uses a different language, then one system uses three or so languages, so you have to have a good command of each language, right? For every language, the company has to have a better one, right? Cost is high not to say, difficulty is also big many!

Fault tolerance

The system is divided into services according to the business. Compared with single applications, more systems are running, and the probability of unavailability of the system as a whole is reduced, but the probability of problems in a single service is increased. This requires a microservice system to have better fault tolerance than a single application!

Any service can fail due to vendor unreliability, and the client needs to optimize its response to this scenario as much as possible. This is a disadvantage compared to a monolithic architecture because it introduces additional complexity. This will keep the microservices team focused on the user experience in the event of a service failure.

Because a service can fail at any time, it is important to quickly detect faults and even automatically recover from changes. Microservices applications place real-time monitoring at all stages of the application, detecting architectural elements (requests received per second to the database) and business-related metrics (orders received per minute). Monitoring systems can provide an early failure warning system for development teams to follow up and investigate.

This has virtually raised the technical requirements for developers!

scalability

For Internet products, this is a must!

I have seen a sentence on the Internet that goes something like this: “When you have an idea, there may be 10,000 people in the world who also have this idea! 1000 of them have started it! 100 of them have finished it!

That is to say, the same product thousands and thousands of times. Why do users prefer yours?

Your system needs to have core competencies to attract new users! At the same time, we need to constantly add new features to keep users from losing!

maintainability

As the number of services increases, so does the cost of maintenance. In addition to improving maintainability by reducing communication costs mentioned above, microservices also reduce maintenance through “infrastructure automation”!

There are several reasons for infrastructure automation:

  • Deploying a microservice is more complex than deploying a monolithic application because there are many more services available for microservices. It is not practical to deploy manually only by operation and maintenance
  • A large number of deployed services and network communication result in the invocation of multiple services for a request. Therefore, request tracing cannot rely on logs as a single application does. Requests need to be tracked.
  • There are some common situations that need to be handled automatically when a request or service is abnormal (also related to “fault tolerance” above)

The resources

  • Microservices
  • Conway’s Law — A Theoretical Basis for the Microservice Architecture
  • Five minutes to understand handu Yi House from 200,000 to 1.5 billion
  • How Do Committees Invent