Devops software architecture evolution

Software architecture evolution

1. from devops From the perspective of software architecture
2. Decision makers : Software architecture is made up of decisions
3. Make up a pie : Components + Connections + constraint

1. Monomer architecture

1. All functions of a single application are integrated together as a single unit
2. The single architecture is more used as the deployment architecture of applications , Not necessarily running in a process .

2. Layered architecture

2.1. " Separation of concerns " From an ideological point of view

1. A system in which software is divided into four layers ( The presentation layer + The business layer + Persistence layer + The data layer , Adjacent layer access )
2. advantage : Simplified structure , Conducive to organizational development , Easy to test independently 、 maintain
3. shortcoming : It is not conducive to continuous release and deployment 、 Performance cost 、 Expandability of

2.2. Service Oriented Architecture (SOA)

1. Delay the binding time as much as possible , Runtime binding
2. Use a collection of distributed components , these Components Provide services for other components , perhaps consumption Services provided by other components , Without knowing the implementation details of other components .
3. Enterprise service bus (ESB)： Provide a supporting environment for mutual invocation of services before , Routing messages between services , And the necessary transformation of messages and data .
4. Service choreography engine (Orchestration Engine): According to the predefined Script Command between service consumers and service providers

5. characteristic :
   1. Service comes from height , Services are loosely coupled , Minimize interaction in development and maintenance
   2. Good operability
   3. Modularization , High reusability
   4. Service dynamic identification 、 Ancestral book 、 call
   5. System complexity increases
   6. Difficult to test and verify
   7. The evolution of independent services is uncontrollable :BSS Influence
6. principle :

2.3. Features of microservice Architecture

2.4. The challenge of microservice Architecture

3. Cloud native applications (Cloud nativa SaaS)

4. Microservice architecture

4.1. What is microservice architecture (MicroServices)

1. 2012 Microservice architecture was proposed in
2. A way to develop a single application into a set of small services , Each service runs in its own process , Lightweight communication mechanism is adopted for inter service communication , Built around the grid business capability, it can be deployed independently through the automatic deployment mechanism .
3. A small, autonomous system , Distributed asynchronous , After that, a series of small services are arranged in the way of arrangement

4.2. Features of microservice Architecture

1. Through service componentization :
   1. A component is a software unit that can be replaced or upgraded independently , The microservice architecture decomposes into services in a componentized way .
   2. A service is an out of process component , adopt Web Service request or remote invocation (RPC) Mechanism communication .
   3. The main reason for using services as components is that services can be deployed independently .( Conform to cloud computing )
   4. More clearly reflect the definition of services .
2. Organize around business capabilities
   1. At the technical level, the division of labor shall be considered ( Cross team communication )-> Carry out wide stack communication around business capabilities .
   2. It is a product model ( Not the project model ), Pay more attention to users , How to improve users' usage
3. Cohesion and decoupling
   1. The goal of the system based on microservices is to decouple and cohere as much as possible , They have their own domain logic .
   2. When the system is divided into separate services , available Domain-driven design Idea , Divide a complex domain into multiple Bound context , And map the relationship between them .
   3. The determination of service and context boundaries helps to clarify and strengthen the separation
4. De centralization
   1. Decentralized governance ( Using different development frameworks 、 Language 、 database ), As long as there are agreed interfaces and deployment specifications
   2. Data decentralization :
      1. Decentralization of data storage ( An enterprise shares a database -> Each microservice uses its own database )
      2. Decentralization of data management ( Business : Guarantee consistency -> No transaction : Pay the cost of maintaining consistency and fixing errors )
5. Infrastructure Automation :
   1. With the automation of infrastructure , Especially Yunhe Web Services It provides implementation possibility for microservice architecture
6. Service design
   1. High availability :( Avoid the problem of call failure ): We set up complete monitoring and logging for each micro service , Help us find out bad behaviors quickly .
   2. Service change and evolution : The component is already in the service , The particle size decreases , Can be published frequently and independently .
   3. Frequently changing parts should be abstracted out : If the service is modified more than once , We should abstract it into a single service .

4.3. The core mode of microservice Architecture

1. Service registration and discovery :
   1. The mechanism for service consumers to obtain service providers , To realize the explanation between the two .

2. API gateway ( Lightweight communication framework ) API Gateway
   1. Provides a single entry point for all clients , Provide different services for different clients API
   2. The client does not care about the application's microservices Split The way
   3. Ensure that the client is not affected by Service instance So far
   4. Provide... For each user The optimal API( The closest )
   5. Lower request Roundtrip frequency
   6. Simplify the complexity of the call

3. Fuse mode :
   1. There is inevitably a dependency relationship between micro services , At the same time, they communicate with each other through the network , Once any service or network problem causes the request error , May cause cascading failure , Gradually enlarge the unavailability in the system

4.4. Implementation of microservice architecture

1. JenKins: Support nearly 1000 A service

4.4.1. Micro service technology selection ( Lightweight )

1. Development services
2. Packaging services
3. Deployment Services
4. Registration service
5. Call the service