Shulou(Shulou.com)06/02 Report--

This article introduces the relevant knowledge of "what are the practical skills of micro-service architecture". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

1. Micro front end

Unfortunately, most back-end developers have a backward view of front-end development and think that front-end development is very simple. Because most software architects are back-end developers, they care little about the front end, which is often ignored in architectural design. In micro-service projects, back-end databases are often highly modular, but there is a Monolith front end. Where appropriate, developers will consider using one of the hottest SPA (React,Angular,Vue) to develop Monolith front ends.

But the main problem is that the front-end Monolith is as bad as the back-end Monolith described by the author in the article "Micro Services Architecture: introduction and necessity for Application in the Project" (MicroserviceArchitecture: A brief overview and why you should use it in your next project).

In addition, changing browsers to keep the front end synchronized requires a big bang of modernization (which is why many companies are still using the outdated Angular 1 framework). The network is simple but powerful, and provides embedding itself. There are many ways to develop SPA based on the micro front end: using iFrame, Web components, or through Elements (Angular / React).

two。 Continuous delivery

A key USP of the microservice architecture is that each microservice can be deployed independently. If the system has 100 microservices and requires a change to one microservice, you can update only one microservice without changing the other 99 microservices.

However, deploying 100 microservices (DevOps,CI / CD) independently without automation is a daunting task. To make full use of this micro-service function, CI / CD and DevOps methods are needed. With a micro-service architecture without CI / CD,DevOps, automation is like buying the latest Porsche and then braking manually. Not surprisingly, CI / CD is listed by microservices expert Martin Fowler (Martin Fowler) as one of the three prerequisites for using a microservices architecture.

3. Micro service priority

Many experts believe that for undeveloped (new) projects, it is best to start with a loosely coupled monolithic architecture, because the microservices architecture requires a lot of initial work to set up operations.

Experts believe that once the project becomes mature enough, the "smart" design of Monolith can be easily converted into micro-services. However, the author believes that this method will end in failure in most cases. In fact, the modules within Monolith are tightly coupled, which makes it difficult to convert into micro-services. Similarly, once the application is officially put into production, it becomes more difficult to convert to a microservice without interrupting the application. Therefore, if there is eventually a plan to use a micro-service architecture, it is recommended to use micro-services in the first place.

4. The infrastructure of the library.

In the early days of micro-service software development, Netflix mainly used Java programming to develop micro-services. Netflix also develops a number of libraries (including Hystrix,Zuul 's Netflix OSS Stack). Many companies follow the example of Netflix and start using the Netflix OSS library. Later, many companies (including Netflix) discovered that Java was not the de facto language for developing microservices because Java was huge and had cold start problems.

Netflix later switched to the Polyglot micro-service paradigm and decided not to develop Netflix OSS further, which led to difficulties for companies that followed Netflix. Therefore, instead of investing heavily in language-specific libraries (such as Java-based Netflix OSS), it is more sensible to use frameworks such as service grids, API gateways.

5. Domain driven design

The big challenge in developing microservices is to split large, complex applications into small, manageable, and independently deployable modules. If microservices do not split applications in the right way, there will be tightly coupled microservices that will have all the shortcomings of Monolith and all the complexities of microservices (also known as distributed Monolith).

Fortunately, there is already a solution that can help a lot in this regard. Eric Evans (Eric Evans), a software engineering consultant, has encountered problems with complexity in business applications many times in different companies, and summed up valuable insights in his 2004 book, Domain-driven Design: solving complexity at the Core of Software. The core concepts of the book can be divided into three categories:

The software development team should work closely with business units or domain experts.

Architects or developers and domain experts should first make strategic designs: find bounded contexts and related core domains, common languages, subdomains, and context mapping maps.

The architect or developer should then make tactical designs to break down the core domain into fine-grained building blocks: entities, value objects, aggregations, aggregation roots.

A detailed discussion of domain-driven design is beyond the scope of this article, but you should read the original book, Eric Evans (Eric Evans), Domain-driven Design: solving complexity in the Software Core (Blue Book) or implementing Domain-driven Design (Redbook) by Vaughan Vernon (Vaughn Vernon). If a large system is divided into core domain and sub-domain, and then the core domain and sub-domain are mapped to one or more micro-services, the ideal loosely coupled micro-services can be obtained.

6. Observability

One of the main disadvantages of micro-service architecture is that it makes software development simple at the cost of operation. It is easier to monitor applications using Monolith. However, because many micro-services run on containers, the observability of the entire system becomes critical and complex. Even logging has become so complex that logs from many containers or machines cannot be aggregated into one central location.

Fortunately, there are already many enterprise-level solutions on the market. For example, ELK / Splunk provides logging for microservices. Prometheus / AppDynamics provides industry-level monitoring. In the field of microservices, another very important observability tool is Tracing. Typically, an API request for a microservice results in multiple cascading calls to other microservices. To analyze the delay of a microservice system, it is necessary to measure the delay on each microservice. Zipkin / Jaeger provides excellent tracking support for microservices.

7. Unified technology stack

The micro-service architecture indicates the need to adopt the programming language and framework that are most suitable for micro-services. This should not be taken literally. Sometimes, microservices may require new technology stacks, such as C + + / Rust for heavy or high-performance tasks in CPU. If microservices can be used with machine learning, perhaps Python is a better choice.

However, without any good reason, using different programming languages or frameworks may result in too many programming languages and frameworks without any real benefits. Imagine a scenario that uses Spring Boot + Kotlin + React + MySQL to develop one microservice, JakartaEE + Java + Angular + PostgreSQL to develop another microservice, and Scala + Play Framework + VueJS + Oracle to develop another microservice, which requires a lot of effort to maintain different programming languages, databases, and frameworks, but with little gain.

8. The database of each microservice

After splitting a complex application into micro-service modules, the next challenge arises-- how to deal with the database?

Whether databases should be shared between microservices. The answer to this question is a double-edged sword, with both advantages and disadvantages.

On the one hand, sharing databases between micro-services will bring strong coupling, which is contrary to the goal of micro-services architecture. Even if there are minor changes in the database, synchronization between teams is required. Similarly, managing transactions and locking databases is also challenging in a service. However, managing transactions or locking databases between multiple distributed microservices is a daunting task.

On the other hand, if each microservice has its own database or dedicated table, exchanging data between microservices presents the challenge of opening Pandora's magic box. As a result, many prominent software engineers advocate sharing a practical solution between microservices. However, the author believes that micro-service is a sustainable and long-term software development process. Therefore, each microservice should have its own database (or dedicated table).

9. Asynchronous communication

One of the challenging design decisions in microservice architecture is how to communicate and share data between services. This is especially important when each microservice has its own data store.

Typically, a microservice can exist alone, but it cannot meet all business goals alone. All microservices work together to achieve business goals and continue to work together, and these microservices need to exchange data or trigger other microservices to complete tasks. The simplest and most common way to communicate between microservices is through Synchronous REST API, which is practical, but not a long-term solution. If service An invokes service B, service B invokes service C, and service C invokes service D synchronously, the delay is superimposed.

In addition, because micro-services are mainly distributed systems, there may be failures. Synchronous microservices usually lead to failed cascades, that is, a failure in one service may lead to the failure of other services. Synchronous communication between microservices also leads to tight coupling between microservices. For a long-term solution, microservices should communicate asynchronously. There are many ways to communicate asynchronously between microservices: for example, through Message QueueKafka, through asynchronous REST (ATOM) or CQRS.

10. Organizational considerations

About 50 years ago (in 1967), Melvin Conway (Melvin Conway) observed that a company's software architecture was limited by organizational structure (Conway's Law). Although the discovery is 50 years old, the Massachusetts Institute of Technology and Harvard Business School recently found that the law is still valid in modern times. If an organization plans to develop a microservices architecture, the team size should be increased accordingly (two "American" pizza teams: 5 or 9). In addition, the team should be cross-functional and ideally have front-end or back-end developers, Ops engineers, and testers. The microservices architecture works only if senior management changes their views and visions accordingly.

This is the end of the content of "what are the practical skills of micro-service architecture". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.