Many friends and colleagues have asked me this question: why are we doing microservices architecture? Isn’t it convenient to roll out code from scratch on a project? It’s faster to develop and easier to deploy. And when it comes to micro services, there is a lot of technology involved, which seems to take several lifetimes to learn.

How to solve this problem? I would like to start with the history of architecture and explain why various architectures emerged today. Only when we have an overall understanding of the context of the architecture, can we evaluate an architecture in a more comprehensive way. To this end, we have a reason to sort out the context of architecture development, why microservices come into being, and what the main problems they solve. Is the Microservices Architecture state of the art?

In this article we explore architectural changes. And the evolution of technology from a Java engineer’s point of view, and what technologies are involved when we talk about microservices. What’s next for microservices? After reading this article, you will know:

  1. The history of software architecture
  2. Differences between SOA architecture and MSA architecture
  3. What are the core concerns of microservices architecture
  4. How to choose the technology of microservices architecture
  5. Where is the architecture heading
  6. Must architecture upgrade be the latest architecture technology in relation to business development? What is a good architecture
  7. What are the difficulties of micro-services, which are mainly left for you to think about and will be further explained in the subsequent articles

First, let’s review the overall history of architecture.

0. History of architecture

Architecture has evolved with its flaws, and here’s a rough history of architecture evolution:

70~80s: Centralized (Mainframe)

In the 1970s and 1980s, mainframes were the way computers worked.

The problem: The first mainframe computers used punch cards, and most calculations were done in batch processing. There is no online processing, and the latency is 100% because there is no real-time processing.

Architectural evolution: With the introduction of online processing and user interface terminals, the mainframe paradigm has undergone some changes.

90S: CS architecture (distributed)

The client/server architecture puts most of the logic on the server side and some of the processing on the client side.

The problem: In the early years of the architecture, the development community was still using the same process as mainframe development, adopting the single-layer principle of writing software for client/server, resulting in anti-patterns such as spaghetti code and BLOBs.

Architectural evolution: Introduced a major improvement called object-oriented programming (OOP);

The client/server model is based on a three-tier architecture consisting of a presentation layer, a business logic layer and a data layer. But most applications are written using a two-tier model, where a fat client encapsulates all presentation, business, and data access logic and accesses the database directly. Although the industry has begun to talk about the need to separate presentation from business and data access, this practice has not really become critical until the advent of Internet-based applications.

2000: Decentralization (Internet)

In the mid 90’s, the Internet revolution took place, with Web browsers becoming client software and Web and application servers hosting all processing and logic.

The problem: Developers are still designing software to be tightly coupled, leading to confusion and other anti-patterns.

Architecture evolution: As a solution, the industry has proposed three-tier architectures and practices, such as Domain-driven Design (DDD), Enterprise Integration patterns (EIP), SOA, and loose coupling technologies.

2006: Cloud hosting

The first decade of the 21st century saw a major shift in cloud computing as a form of service hosting. Cloud computing platforms host the basic functions needed by applications: distributed computing, networking, storage, and computing. Compared with traditional infrastructure, cloud hosting can control costs better.

The problem: It induces the direct migration and migration of legacy applications that have not been designed for an elastic distributed architecture into the cloud, creating the singleton hell anti-pattern.

Moving to the cloud also presents the industry with the challenge of managing third-party libraries and application dependencies on technology. Without enough criteria to choose from third-party tools, we’re starting to see some dependency hell. Service expansion is also a problem.

Architecture evolution: In response to these challenges, the industry has proposed new architectural patterns, such as microservices and 12-factor applications 8, Resilient Services.

2014: Microservices

Software design such as DDD and EIP has been in practice since around 2003, when some teams developed applications as modular services, but traditional infrastructures such as heavyweight J2EE application servers and Java applications. IIS for NET applications) does not help with modular deployment.

With the advent of Cloud hosting, especially with PaaS products like Heroku and Cloud Foundry, the developer community has everything it needs for truly modular deployments and scalable business applications. This led to the development of microservices. Microservices offer the possibility of creating fine-grained, reusable functional and non-functional services.

The problem: The monolithic systems, the traditional applications that were not designed as microservices, began to be cannibalized and tried to force them into microservices architecture, resulting in an anti-pattern known as micromonomer due to improper dismantling. Singleton and microservice are two different models, and the latter is not always a substitute for the former. If we’re not careful, we can end up with tightly coupled, jumbled microservices. Another unwanted side effect of the proliferation of microservices is the so-called “death planet” anti-pattern.

Architectural evolution: Emerging architectural patterns such as service grids, sidecars, service choreography and containers can effectively defend against malfeasance in a cloud-based world. With the emergence of cloud platforms, especially container choreography technologies like Kubernetes, service grids have attracted much attention. The service grid is a bridge between application services that can add additional capabilities such as flow control, service discovery, load balancing, resiliency, observability, security, and so on.

Several architectural antipatterns3instructions

  • Monomer hell4:
    • Benefits: Easy early development, easy to make major changes to the program, direct testing, direct deployment, easy to expand;
    • Disadvantages: As business grows, problems are exposed: high complexity, low development efficiency, long time from commit to deployment, poor scalability, outdated technology stack difficult to upgrade, lack of fault isolation so that a small function can affect the entire system;
  • The monomer5:
    • An inelastic and non-extensible microservice system, the so-called micromonomer; Singleton and microservice are two different models, and the latter is not always a substitute for the former. If we are not careful, we can end up with tightly coupled, jumbled microservices (microsingletons). We should make choices based on the business and scalability requirements of the application functionality;
  • towerMonolithic applications are similar to building blocks: you never know which brick might go wrong when something goes wrong. Because all modules of the application run in the same process, if one module is affected by an error, the entire process is degraded, affecting the entire application. You may lose hundreds or even thousands of business opportunities before troubleshooting is complete;
  • frankenstein7Frankenstein is a famous American film about a genius scientist who creates a monster that eventually destroys him. The Istio team makes fun of it. Istio intended to play the role of God (unifying Service Mesh and becoming the de facto standard for microservice architectures), but it became a monster because of overdesign and disconnection from reality. Therefore, the first stage of the refactoring, starting with the dismemberment of the monster, is to change the microservices architecture back to a monolithic architecture, but the internal module division is still very clear;
  • The wheel: Reinventing the wheel of fang, having already had a good plan, making another plan to replace it;
  • The death star6:
    • Without a governance model in terms of service interaction and service-to-service security (authentication and authorization), the proliferation of microservices often leads to situations where any service can call any other service at will. You could have a call view like death Planet, very complicated. Emerging architectural patterns such as service grid, sidecar, service choreography and containers can effectively defend against malfeasance in a cloud-based world;
  • Spaghetti designNoodles are so intertwined that it is difficult to tease out the relationship between them. Spaghetti design vividly illustrates this phenomenon in software development: the system is difficult to maintain, all kinds of functional logic intertwined, there is no clear module and hierarchical relationship;
  • The Blob: indicates that a type has too many functions, making it too big and ultimately hard to maintain.

Architecture evolution Steps

Generally speaking, the emergence of each architecture, not overnight, will go through the following processes:

  • Introducing new models;
  • Best architectural practices are unknown or non-existent;
  • Antipattern, technology debt surge;
  • The industry develops new architectures to accommodate new paradigms;
  • The team researched and adopted a new standard architecture;

Let’s take a look at the rough history of architecture from a Java engineer’s perspective.

1. Stage 1: Learn SSH framework well and go anywhere

In the early days, most IT systems were monolithic systems, such as the traditional SSH architecture, where the front and back ends were not separated and UI components were included in the control layer:

In this period, the service object is mainly traditional enterprises, with low concurrency, mainly business development, which is very convenient. When I first graduated, my classmates and I wondered if Internet companies were using SSH frameworks.

What’s the real story? With the rise of Internet enterprises, DAU continues to grow, and the amount of concurrent services gradually increases. The simple deployment of single JVM in SSH architecture cannot meet the high concurrency scenarios, and we need an architecture that can support the horizontal scaling of the system.

2. The second stage: distributed system

In order to facilitate the expansion of the system, and increase the reuse of the system, the emergence of distributed systems.

On the other hand, the system module expands rapidly. In order to reduce the internal complexity of the system, the system module is disassembled so that it cannot be divided into different systems, which reduces module coupling and speeds up iteration.

The industry has proposed three-tier architectures and practices such as domain Driven Design (DDD), Enterprise Integration patterns (EIP), SOA, and loose coupling technologies.

3, SOA

Early distributed systems were based on a service-oriented architecture called SOA. SOA is the predecessor of microservices, mainly to get rid of the problem of single application, to achieve the following effects:

  • Make full use of existing infrastructure;
  • SOA architecture relies on messaging (AMQP, MSMQ) and SOAP as the primary remote access protocols.
  • Quick response to business changes;

Based on the introduction of an Indian boy, I drew the following SOA architecture diagram:

In other words, heterogeneous systems can also call each other through protocol transformation of message-oriented middleware. Typically this message-oriented middleware is implemented using ESB Enterprise Bus. ESB is the product of the combination of traditional middleware technology, XML, Web services and other technologies. It eliminates the technical differences between different applications, enables different application servers to coordinate operation, and realizes the communication and integration between different services. Different companies provide different ESB middleware implementations.

But its performance is not good, mainly because it is too heavy, mainly reflected in:

  • SOA emphasizes the standardization and convenience of system integration, and does not have too many requirements for business services themselves. Generally, the granularity of service separation is not fine enough, and there will still be relatively large coupling between modules, making it difficult to iterate.
  • Communication between SOA services is relatively complex and heavyweight. SOAP communication protocol commonly used in WebService, usually using XML format for communication, data redundancy, protocol overload; EBS hides internal complexity through the bus, and its centralized management mode and system changes expand the scope of influence on the system.
  • Under SOA model, there is usually only one database, which limits the scalability of the system.
  • Service management and governance facilities are not perfect;

Later, it evolved into the current MICRO-Service Archeticture (MSA), which enables looser coupling and more flexible systems.

4. Microservices (MSA)

Microservices replace the bus in SOA with the idea of individual sub-service control modules. Service control module usually contains at least: service registration and publishing, routing, proxy.

Microservices vs. SOA

  • Objective:
    • SOA emphasizes collaboration and contract between heterogeneous services, emphasizes effective integration and maximizes the reusability of application services.
    • The purpose of microservices isDecouple applications and focus on decoupling, let different business teams serve different micro-services, and assign special personnel to focus on them, so as to narrow the scope of influence of iteration and make micro-services easier to carry outHorizontal scaling;Microservices follow a single responsibility and are a decomposition technique to overcome system complexity.If you feel that one of your microservices is complex, consider whether it’s not broken down enough. And because of this unbundling, essentiallyEnhanced securityandFault isolation;
  • Deployment mode:
    • There are not many SOA services, which are usually packaged and deployed directly to the server in the form of WAR.
    • Due to the large number of microservices, rapid expansion and reduction of capacity need to be realized. Generally, container technology is used to achieve deployment. Microservices are independently deployed and do not affect each other.
  • Service granularity:
    • SOA has no requirements for granularity, usually coarse-grained, with more emphasis on interface normalization;
    • Microservices advocate a fine-grained separation to ensure a single service responsibility.
SOA Micro service
Service granularity Granularity coarser Fine particle separation
Deployment difficulty The entire application needs to be recreated or deployed Each microservice can be built and deployed independently
Communication overhead Most of the service modules are in one application and the communication overhead is low More remote calls, increased communication overhead
storage Generally, all services share data stores Each can have separate storage
Easy to get started You need to understand the business of the entire application, which is difficult to get started A single service is easy to learn, but a service cluster is difficult to understand (Conservation of complexity:Business complexity is not reduced by the migration to microservices)
Communication mode SOA architecture relies on messaging (AMQP, MSMQ) and SOAP as the main remote access protocols, which are heavyweight; Use lightweight protocols, such as HTTP/REST
scalability Difficult to extend Using container technology is easy to extend

4.1 advantages of microservices

4.1.1 Facilitate capacity expansion and ensure service scalability

It is because of the microservices disassembly that we have increased the security and failure isolation of the system, allowing us to implement different capacity expansion and storage technologies for different services.

For example, some microservices might use relational databases, while others might use NoSQL databases or even mounted file systems. Building applications in this way increases the scalability of the team building applications.

4.1.2 Reduce coupling, which is conducive to team collaboration and rapid version update

In SOA systems, or in traditional monolithic systems, when using a project, there is usually a large team of people working on the same branch of the project, always interfering with each other, with various code conflicts, and exponential growth as the code grows. This is a problem we have encountered before, especially headache, later spent a lot of energy to do service transformation of the system split.

Of course, leading this service-oriented transformation also needs to apply for a lot of resources, even if there is no new business online. In order to make the boss think that the transformation we are doing is valuable, we also wrote a variety of advantages and disadvantages comparison before and after the transformation. This is very important, we can’t just change a system that works well for no reason.

With microservices architecture, applications are built by small, decentralized development teams that work independently and change microservices.

4.1.3 Service autonomy

This makes it easier to test and upgrade services and add functionality over time.

Ultimately, if a microservice grows in size and functionality, it can be broken down and divided into multiple microservices, keeping microservices small, manageable, and autonomous.

4.1.4 Keep technical diversity of the project

Finally, adopting a microservice architecture allows individual services to be written using whatever language and technology stack is best suited for their development. There is no strict restriction that all microservices must be developed using the same technology, as long as they all communicate over the same lightweight protocols (such as HTTP and messaging) and data structures are serialized in the same format (JSON is the most popular choice).

The characteristics of microservices are:

  • Lightweight components;
  • Service independent deployment capability;
  • Lightweight, coarse-grained apis;
  • Lightweight service bus;
  • Lightweight data storage;

4.1.5 The problem of low efficiency of single system development is avoided

Monolithic systems are either getting too big for their databases or too many lines of code, or more likely, developers today can’t add new features quickly enough. Microservices architecture avoids the pitfalls of monolithic systems, uses real and reliable decomposition techniques to address them, and focuses on agile development and replaceable rather than reusability.

Moreover, unlike monolithic systems, microservices are a sustainable architecture that addresses rapidly changing business needs by adding new microservices rather than modifying (and breaking) old ones.

4.2 Problems faced by micro-services

No architecture is free

While microservices have many benefits, they are not a panacea. While microservices alleviate many of the problems inherent in overall applications, they also present other challenges. As with anything in technology, there are always trade-offs between different architectures and microservices.

4.2.1 Increased the complexity of operation and maintenance and maintenance of micro-service cluster

The agility and speed of development it provides comes at the expense of increased operational complexity, as there are naturally more moving parts (or services) — perhaps more than individual applications.

The use of a microservice architecture may increase operational overhead. With this approach, your deployment may require a lot of resources. You may need more time and effort to create the infrastructure. All services may require clustering for failover and resiliency. Your system may have dozens of separate components, and it gets more and more complex as you add new functionality.

Instead of an overall system, you might end up with a solution of 20 or 30 or more services, each running multiple processes.

As a best practice, you should address this additional work overhead through DevOps automation.

4.2.2 It is difficult for single system to migrate to micro-service price comparison

** Migrating monolithic systems to microservices is also a huge effort. ** It is not recommended to rewrite systems with microservices, which is not practical, especially if the business of a single system is complex. A more gradual approach is recommended, gradually refactoring a monolithic system and gradually transforming it into a “new” application made up of microservices. Over time, the number of functions implemented by a single application diminishes until it disappears entirely or becomes just another microservice application. Finally, don’t feel the need to start breaking everything down immediately; Spend time and work in the most reasonable way for your team.

4.2.3 Improve the technical threshold of development

Before starting the actual migration process, consider the following trade-offs: To be sure, systems with microservices architectures offer a number of benefits, such as independent deployment, strong subsystem boundaries, and technological diversity.

However, because microservices are a distributed system, it comes at the cost of complexity associated with developing distributed applications, such as independent data models, elastic communication between microservices, ultimate consistency, and operational complexity. Nor is it easy to develop and run large-scale distributed services.

In the actual process of splitting a single system into microservices, ** it is not recommended to measure the splitting effect by the size of the service, but the business boundary of the splitting. DDD method can be considered for modeling design. **DDD is an excellent tool in our architect’s toolbox for identifying and designing microservices.

4.3 Microservice technology system

There are many points that need to be paid attention to in micro-services. The following is a graph to express it:

In general, the microservices MSA architecture requires the support of the following technical points:

  • Configuration management;
  • Service discovery and load balancing;
  • Flexibility and fault tolerance;
  • API management;
  • Service security;
  • Log management;
  • Metrics monitoring;
  • Distributed call chain tracing;
  • Scheduling and publishing;
  • Automatic expansion and self-healing;

In addition to technology related, organizational structure and team culture are also important.

Here are the various components involved in general microservices:

5. Selection of micro-service technology

Let’s start by looking at the pros and cons of the various technology stacks for microservices.

5.1, Spring Cloud

Developers are provided with tools to build MSA, such as configuration hubs, service discovery, circuit breakers, routing, and so on. It is built based on the Netflix OSS library in Java.

For information on how to build a Microservice architecture using The Spring Cloud, it is recommended that you read: Microservice Architectures With Spring Cloud and Docker.

5.1.1, strengths,

  • Spring technology stack, quick to get started and out of the box: The Spring platform provides a unified programming model and Spring Boot’s ability to quickly create applications, providing developers with an excellent microservices development suite that requires very little configuration to create applications;
  • Rich component library;
  • Different Spring Cloud components work well together, are annotation-driven, easy to develop, and feel like a Java developer’s paradise.

5.1.2 and disadvantages

  • Java only. We mentioned earlier that the beauty of the MSA architecture is the ability to modify the technology stack, library, and even language as needed. Spring Cloud can’t do that. Netflix’s Prana project uses sidecar mode to integrate non-JVM applications into the system through HTTP calls. Cross-process communication with Prana over HTTP enables applications written in other languages or services such as Memcached, Spark, and Hadoop to take advantage of features provided by Netflix’s OSS library without having to rewrite the library for the target language or platform;
  • Java programmers take on too much responsibility. Service discovery, load balancing, configuration center all need to be deployed separately, and we need to ensure high availability. In addition to implementing service functions, we have to build and manage a microservice platform.
  • Failure to cover the entire MSA life cycle: Some essential functions of the microservice platform are missing, and automated deployment, scheduling, resource management, process isolation, and self-repair are still problems. We still need to introduce Kubernetes or Cloud Foundry to solve these problems.

5.2, Dubbo

Dubbo is just an RPC framework with the following architecture (from official website 2) :

Call Relationship Description

  1. The service container is responsible for starting, loading, and running the service provider.
  2. When the service provider starts up, it reports to the registryregisteredThe services they provide.
  3. At startup, the service consumer calls the registryTo subscribe toThe services you need.
  4. The registry returns a list of service provider addresses to the consumer, and if there is a change, the registry will base it onA long connectionPush change data to consumers.
  5. The service consumer, from the provider address list, based onSoft load balancing algorithm, select one provider to call, and if the call fails, select another.
  6. Service consumers and providers accumulate calls and call times in memory, regularly sending statistics every minuteThe monitoring center.

It provides Metrics monitoring, service discovery and load balancing, RPC calls. It is not really an MSA system, but later Alibaba integrated Spring Cloud and launched Spring Cloud Alibaba as a one-stop solution for microservice development. This includes the Dubbo Spring Cloud.

Since Dubbo Spring Cloud is built on top of the native Spring Cloud, its service governance capabilities can be considered as Spring Cloud Plus, which not only fully covers Spring Cloud native features, but also provides a more stable and mature implementation:

  • Service traffic limiting degradation: Default support for WebServlet, WebFlux, OpenFeign, RestTemplate, Spring Cloud Gateway, Zuul, Dubbo and RocketMQ traffic limiting degrade function access, You can modify traffic limiting degradation rules in real time through the console at runtime and view the Metrics of traffic limiting degradation.
  • Service Registration and Discovery: It ADAPTS to the Spring Cloud Service Registration and Discovery standard and integrates Ribbon support by default.
  • Distributed configuration management: Supports external configuration in distributed systems, and automatically refreshes configuration changes.
  • Message driven capabilities: Build message driven capabilities for microservice applications based on Spring Cloud Stream.
  • Distributed t Transactions: Solve distributed transaction problems efficiently and without intrusion to the business using the @GlobalTransactional annotation.
  • Ali Cloud object storage: Ali Cloud provides massive, secure, low-cost and highly reliable cloud storage services. Supports storage and access of any type of data in any application, anytime, anywhere.
  • Distributed task scheduling: provides second-level, precise, highly reliable, and highly available scheduled (Cron expression based) task scheduling services. It also provides a distributed task execution model, such as grid tasks. Grid tasks allow quantum tasks to be evenly distributed to all workers (schedulerx-client) for execution.
  • Ali Cloud SMS service: global SMS service, friendly, efficient and intelligent interconnection communication capabilities, help enterprises quickly build customer access channels.

5.3, Kubernetes

Kubernetes is an open source system for automated container deployment, extension, and management of applications. It supports multiple languages and provides primitives for configuring, running, extending, and managing distributed systems.

advantages

  • Multilingual and universal container management platform, capable of running cloud native and traditional container applications;
  • Easy to build cross-team platforms: services provided (such as configuration management, service discovery, load balancing, metric collection, log aggregation) can be used in multiple languages;
  • Addressing more MSA issues: In addition to providing runtime services, Kubernetes allows you to set up environments, set resource constraints, RBAC, manage application life cycles, enable auto scaling, self-repair, and more;
  • Vibrant communities and rapid technology development;

disadvantages

  • Platforms with generic services and primitives that are not optimized for a specific language or platform make it difficult to get started;
  • Not to the developer is not the center of the platform, is committed to creating a DevOPs-aware IT staff use, manual installation of highly available Kubernetes cluster requires tedious operation and configuration;
  • Is a relatively new platform, still evolving, each version will add a lot of features, new features are more difficult to keep up; But it provides more apis that are extensible and backward compatible;

Here’s a table to summarize

Technology stack advantages disadvantages
Dubbo Ali endorsement;

Mature and stable;

RPC high performance;

Flow management;		 High coupling;

Only Java is supported;

Small community abroad
Spring Cloud Spring technology stack, quick to use, out of the box;

Rich component library;

Different Spring Cloud components work well together, all annotation-driven		 Limited to Java

JavaProgrammers take on too much responsibility

Cannot cover the entire MSA life cycle
Kubernetes Multilingualism and versatility;

Easy to build platforms across teams

Cover the entire lifecycle of the MSA;

Active community;		 Services and primitives are universal, and the technical threshold is high.

Cumbersome configuration, DevOps and o&M bias;

The platform develops rapidly and changes rapidly.
## 5.4 selection of MSA technology

Dubbo is just an RPC framework and does not provide functionality that covers the entire MSA life cycle.

Spring Cloud is a developer-friendly platform for getting started quickly.

Kubernetes is DevOps-friendly and has a steep learning curve, but offers more solutions to microservice problems.

Spring Cloud is very powerful inside JVMS, and Kubernetes is very powerful in managing those JVMS.

Ability to Dubbo Spring Cloud Kubernetes Other technologies
Distributed call chain tracing / Spring Cloud Sleuth Zipkin Skywalking,
Metrics monitoring Dubbo Admin/Monitor Actuator/MicroMeter metrics-server Prometheus, Grafana
Centralized log management ELK ELK EFK
Task management Spring Batch CronJob ElasticJob/XXL-JOB
Service discovery and load balancing zk/Nacos + client Eureka + Ribbon Service
API gateway / zuul Ingress
Configuration management Diamond/Nacos Spring Cloud Config ConfigMaps/Secrets
The application package Jar/War Jar/War Docker Image/Helm
Automatic expansion and self-healing / / Pod/Cluster Autoscaler, the Scheduler
Publishing and scheduling / / Deployment Strategy, A/B, Canary, Scheduler Strategy
Process isolation / / Docker, Pods
Environmental management / / Namespaces, Authorization
Resources quota / / CPU and Memory limits, Namespace Resource Quotas
IaaS GCE, Azure, CenturyLink, VMWare, Openstack

Based on the above comparison, there are many technologies to choose from when we want to build a complete microservices architecture. So how to choose

The following is the recommended technology selection scheme:

  • If it is a new team to do the selection of technology, it is recommended to directly go to Kubernetes, of course, you can use Spring Boot. To improve the efficiency of internal service invocation, dubbo can be integrated, but it is recommended to use Kubernetes’ built-in service discovery and load balancing, that is, to minimize the introduction of external technologies;
  • Small and medium enterprises may not have the labor cost to build their own Kubernetes platform, can adoptPublic clouds;
  • Try not to mix and match, which will increase maintenance costs;
  • For historical Dubbo projects, try to migrate toDubbo Spring CloudImprove other components. Use the Dubbo Spring Cloud1, cooperate with Kubernetes to achieve DevOps system. Internal calls are made through Dubbo RPC for efficiency.

The selection of technical scheme is summarized as follows:

6. Architecture selection

There are no good or bad architectures, only the ones that best fit the business.

How to choice

Here’s an example of how architecture selection should be tailored to the business. Let’s start with three architectures:

  • Monomer architecture: A typical single application is to put the presentation layer, business logic layer, and data access layer of all business scenarios into a project, which is finally compiled, packaged, and deployed on a server.
  • Microservices Architecture: Microservice is a large-scale complex software application composed of one or more microservices. Each microservice in the system can be deployed independently, and each microservice is loosely coupled.
  • Serverless architecture: Serverless architecture refers to a large number of applications that rely on third-party BaaS(back-end as a Service) services or custom code FaaS(Function as a Service) running in a temporary container. Functions are the smallest unit of abstract language runtime in a serverless architecture. In Severless architecture, we focus on the time it takes to run functions to calculate how much we need to pay for services.
The architecture type When to adopt When not to use Using case
Monomer architecture The modules in the application are tightly coupled and completely interdependent in the context of transactions. Instant consistency of all data operations is required. Modules in an application can be further decoupled into atomic business services or common technical functions. ERP, CRM
Microservices Architecture Each module of an application is completely independent at runtime and in transaction processing, and the data of each module can be operated in a stateless way. Even if there is coupling between modules, it can also achieve the purpose of decoupling through final consistency. Application modules cannot be deployed and used independently without strictly relying on other modules. Customer service, order service, inventory service
Serverless architecture Application modules with completely independent and separate scalability strategies can be decomposed into individual functions of the business or technology;

When there is no request traffic, the application shuts down completely;

The development team doesn’t have to care about the infrastructure.		 Long-running jobs, CRUD services, or stateful services Authentication, notification, event flow

Architecture upgrade and business development

  • We must introduce a more reasonable technical architecture, constantly develop and optimize the technical architecture, and develop and provide a series of stable business applications running on the technical architecture under the premise of ensuring that the business is not affected.
  • The need to support rapid technology evolution while protecting business applications from technology upgrades;
  • IT leaders who fail to address technical debt in a timely manner risk creating software and organizational challenges. Technology debt disrupts business and creates even more debt, while leading to the savage growth of bad practices and the loss of top talent. Without advanced technological weapons, the best business will be caught up.

7. Cloud native architecture

In the last section we looked at the history of architecture, and we saw that the transition from microservices to cloud native is happening right now. The basic cloud platform provides:

  • Laas will provide us with computing, storage, network and other resource capabilities;
  • PaaS will provide us with a common technology base, and we can use its API directly;

We built our own SaaS system based on the computing power provided by the cloud platform and finally deployed it to the cloud through DevOps. Key levels are divided as follows:

IaaS: Infrastructure-as-a-Service. The Service provided to consumers is the utilization of all computing Infrastructure, including PROCESSING CPU, memory, storage, network, and other basic computing resources. Users can deploy and run any software, including operating systems and applications.

PaaS: platform-as-a-Service provides common technical components to facilitate system development and maintenance. Deploy applications developed or acquired by the customer using provided development languages and tools (such as Java, Python,.NET, etc.) to the vendor’s cloud computing infrastructure;

SaaS: software-as-a-service, which provides developed applications or services for a fee based on functionality or performance requirements. SaaS is software that is developed, managed and deployed by a third party without technical concerns. The average user is exposed to Internet services, almost all SaaS.

Want to learn more about how a single application can be split into microservices and then deployed in the cloud using K8S to move from a single application to a cloud native architecture? Solution architect Andy Wu discusses the issues of monolithic systems, the benefits of microservices, and the benefits of cloud computing on services at Google Cloud Platform. It also demonstrates the process of migrating a monolithic system to this new architecture through a real scenario. Public account reply: G01 obtain first-hand complete information. (English version)

Distributed technology in microservices

When designing microservice system or studying its underlying principle, it will involve all aspects of distributed basic knowledge: distributed transaction processing, distributed lock, distributed ID, distributed cache, distributed search technology, distributed coordination component, message queue and high-performance communication framework Netty. This is a topic we will discuss in the distributed topic.

The content of this article is almost introduced here, can read here friends are really very patient, thumbs up for you.

This article is written by Arthinking based on relevant technical information and official documentation. It is accurate to ensure that the content is correct. If you find any mistakes or errors, please kindly correct them.

You can follow my blog at itzhai.com for more articles, and I will continue to update on back-end technologies, including THE JVM, Java infrastructure, architectural design, network programming, data structures, databases, algorithms, concurrent programming, distributed systems, and more.

If you feel that you have gained something after reading this article, you can follow my account or like it. The code word is not easy. Your support is the biggest motivation for my writing.

Follow my official account for the latest articles.

More articles

  • JVM series topics: Public accounts send JVMS

Author: Arthinking

Blog links: www.itzhai.com/architectur…

Architecture Evolution: Why microservices Architecture?

Copyright notice: copyright belongs to the author, shall not be reproduced without permission, infringement will be investigated! Please add the public number to contact the author.

References

How to choose between SpringCloud and Kubernetes to build a microservices technology platform?

Adoption of Cloud-native Architecture, Part 1: Architecture Evolution and Maturity

A preliminary study on microservice architecture

Spring Cloud for Microservices Compared to Kubernetes

Differences between microservices and SOA

Microservices vs SOA: What’s the Difference?

What is service-oriented architecture?

Microservices vs SOA: What’s the Difference?

Distributed Services Architecture: Principles, Design, and Practice

The Cloud – native – approach – with – microservices”

SpringCloud vs. Dubbo

Dubbo is a perfect combination with Spring Cloud

Microservices Patterns

  1. Use these 12 elements to build your application↩
  2. Software Architecture AntiPatterns↩
  3. Escaping monolithic hell↩
  4. From building microliths to designing reactive microsystems↩
  5. Return to monomer — Istio’s Self-salvation?↩
  6. An open-source benchmark suite for microservices and their hardware-software implications for cloud & edge systems↩
  7. dubbo↩
  8. Dubbo Spring Cloud↩