A summary of Netflix's micro-service architecture design experience!

Migrating to a micro-service architecture can bring exciting opportunities to the company's marketplace because it brings faster new feature launches for users. You know that the success of your future company depends on whether you migrate to a micro-service architecture, but how you do it.

Fortunately, some early micro-service practitioners have generously shared their micro-service practices and contributed to the source code. Adrian Cockcroft–netflix's cloud architect, he saw Netflix from the 100-person traditional application research team, developed a DVD leasing system for the boulder application, evolved to a number of independent small teams, supporting 500 micro-services, 120 million people watching video sites every day.

What is a micro-service architecture?

Cockcroft defines the Micro service as: a microservices architecture as A service‑oriented architecture composed of loosely coupled elements tha t have bounded contexts. Here are two core concepts, one is loosely coupled, and the other is bounded context.

Loosely coupled (loosely coupled) means:

Each service can be updated independently

Updating a service does not require changing other services

If you have a bunch of small services that you can't update independently, that's not a micro-service, because these services are not loosely coupled. One reason is that some companies will split the application, but not split the database, all applications still access the same database, you need to split the database for each service.

The bounded contexts concept is from the Domain driven design book written by Eric Evans. Micro-services need to have a clear boundary, you can focus on the release of your own software, regardless of who is relying on your release version, because the micro-service and its consumers through the API Strictly Interactive, do not share data structures, databases, POJO, etc. The service interface is stable and backward-compatible based on the contractual micro-service specification.

best practices for designing a micro-service architecture

Create a separate data store for each micro-service

Do not provide shared back-end data storage for micro services. Each team has the freedom to choose the best fit for the database. Splitting a database makes data management complex, because independent data stores are prone to data inconsistencies, and foreign keys can easily be accidentally compromised. You need tools to master Data Management (MDM) to fix inconsistent problems for back-end services. For example, you need to check all databases that store user IDs, make sure that each database has a full user ID record, and you cannot have a database without a record. You can implement this tool yourself, or you can use the system tools of the commercial relational database, but often these tools have many thresholds and are not easily expandable.

Keep Code maturity at the same level

Keep Code maturity at the same level, and if you want to add or rewrite a service that's already stabilized, the best thing to do is to keep the services that are running stably and create a new micro-service. This is in line with the immutable infrastructure principle, the book's Immutable Infrastructure theory. This way you can deploy and test new code progressively, until the code is stable enough to run efficiently, without any performance problems or deployment failures, you can Merge the code back into the previous service and complete the development of the new functionality.

provide independent builds for each micro service

Provide an independent build for each micro service so that each service can be built, published independently, and other services rely on a certain version of your knowledge release warehouse, and he can decide whether to upgrade your latest version or continue using the old version. This brings the independence of small teams, each team can decide their own release cycle, responsible for the online issues.

changes in organizational structure

In the micro-service architecture, in addition to the application of refactoring, the structure of the Organization will also change, in order to enable the micro-service team to achieve independent operation, the company must set up a dedicated base platform department, also known as SRE, this department for the company's research and development team to provide a unified product library management, CI tools (Jenkins, Deployment tools and operational dimensions, monitoring platforms, and applications for high availability protection. So that each team can publish their own services independently.

Deploy to Container

Deploying a micro-service to a container is important because it means you need only one tool to deploy all of your content. Once the micro service is placed in a container, the container deployment tool knows how to deploy it, regardless of the type of container.

view server as stateless

To treat a server, especially a server that directly serves a user, you should think of it as a constant change member of an atomic service, and you don't have to consider the state of a machine individually, they should all provide the same function without discrimination.

The only thing you should consider is whether they can support your business volume. You can turn these services on or off using automatic expansion. If one of the services falls down, it should be replaced by a new instance. It is important to avoid a service that has special functionality to be a single point of failure.

Cockcroft's theory is that you should think of the server as a cow in a dairy farm, not a pet. A single cow is marked with a unique number, and the pet is labeled with a name. If your machine uses name tags and handles a particular application, if the machine is down, everyone will be affected.

Conversely, if you think of machines as cows in a dairy farm, you only care about how much milk you produce every day, and if you find that milk production is less than usual one day, you just need to find the wrong cow and replace it.

the Netflix deployment architecture based on NGINX platform

Netflix is a veteran user of the Open-source version of NGINX. Netflix also became the first corporate user of NGINX in 2011, and NGINX and NGINX Plus has provided support for Netflix with thousands of-millions of concurrent requests per second as a high-performance HTTP processing solution.

Resources:

https://www.nginx.com/blog/microservices-at-netflix-architectural-best-practices/

Author: does Wang Qing

Currently serving as Jfrog China's chief architect, previously in Ibm,hpe, Archie, Sina, Vipkid and other companies have done research and development and architecture, is more than 10 years experience in the development of the Internet veterans, focusing on software lifecycle management, micro-service architecture, cloud native application, container and other fields. Welcome reprint, but reprint please indicate the author and source. Thank you.