Distributed service framework principle and practice reading notes

1. Traditional vertical application architecture: LAMP, MVC and early EJB, with the continuous development and expansion of the business, there are several challenges

1) The development and maintenance costs of complex applications become higher, and the deployment efficiency gradually decreases

2) The team collaboration efficiency is poor, some public functions are repeatedly developed, and the code duplication rate remains high

3) System reliability becomes worse

4) Maintenance and customization difficulties

5) The launch cycle of new functions becomes longer

The solution to the above challenges is the independence of the core business, the extraction of public APIs, the realization of service sharing, the evolution of interface calls into cross-process remote calls, and the emergence of the RPC framework.

2. RPC framework: The inter-process communication method makes remote procedure (service) calls simpler and more transparent. The RPC framework is responsible for shielding the underlying transmission method (TCP/UDP), serialization method (XML/JSON/binary) and communication details.

2.1 The core technical points of the RPC framework:

1) The remote service provider needs to provide service invocation related information (such as service interface definition, data structure or intermediate service definition file (Thrift's IDL file, WebService's WSDL file)), and the caller obtains this information through a certain way.

2) Remote proxy object: The service invoked by the service caller is the local proxy of the remote service. The implementation of java is the dynamic proxy of the JDK, and the local call is encapsulated into a remote service call through the dynamic proxy.

3) Communication: such as HttpInvoke, RMI Invoke, etc.

4) Serialization: Remote communication needs to convert objects into binary streams for transmission. Different serialization frameworks support different data types, performance, etc., and the applicable scenarios are also different.

2.2. RPC framework implementation example

2.3. Mainstream RPC frameworks in the industry: Apache thrift developed by Facebook, Hadoop sub-project Avro-RPC, caucho's Hessian, google's gRpc based on Http2 and protoBuf

2.4 The RPC framework is service-oriented. As there are more and more services, there are several challenges

1) Difficulty in configuration management

2) The dependencies between services will become more and more complex with the development of the business. A tracking governance system is needed to help architects sort out unreasonable dependencies and prevent service architecture from corrupting

3. SOA service-oriented architecture: a coarse-grained, loosely coupled service-centric architecture for application complex system integration and rapid changes in requirements

3.1 Service-oriented design principles: services are reusable, services share a standard contract, services are loosely coupled, services are said to abstract the underlying logic, services are said to be composable and orchestrated, services are said to be autonomous, services are stateless, services can be automatically discovered

3.2 Challenges brought by SOA service to system operation and maintenance:

1) Service call performance under distributed framework

2) How does service-based architecture support linear expansion

3) How to achieve efficient and real-time service multi-dimensional monitoring

4) Rapid fault demarcation and location in large-scale distributed environment

5) Online retrieval and fuzzy query of massive logs in a distributed environment

6) Service flow control, timeout control, service elevator and other management and control methods

7) The principle of division of services, and how to reuse them to the greatest extent

。。。

Based on the above challenges, SOA service governance is required, which mainly includes the following aspects:

1) Service definition (can also include service mechanism) Chapter 3-8 (communication framework, serialization and deserialization, protocol stack, service routing, cluster fault tolerance, service invocation method)

2) Service Lifecycle Management - Chapters 10 and 11 (Service Publishing and Reference, Service Grayscale Publishing)

3) Service Version Governance - Chapters 12 and 13 (parameter passing, service multi-version)

4) Service Registry - Chapter 9

5) Service Monitoring - Chapter 17

6) Operational Service Quality Assurance - Chapters 14, 15, 16 (traffic monitoring, service degradation, service priority scheduling)

7) Fast Fault Delimitation and Location - Chapters 17 and 18

8) Service Security - Chapters 17, 19

SOA service-oriented architecture solves the problem of application service-oriented. With the deepening of good service practices, the scale of services is large, and the challenges faced are more and more, and micro-services emerge as the times require

4. Microservice Architecture:

4.1 Main features:

1) Atomic service: focus on making submissions, single responsibility principle

2) High-density deployment: Important services can be deployed in independent processes, and non-core services can be packaged independently. When co-located in the same process, services can be deployed in high density.

3) Agile delivery: The service has a small R&D team responsible for design, development, testing, deployment, online governance, grayscale release and offline, and supports the entire life cycle of operation and maintenance to achieve true DevOps.

4) Micro-autonomy: The service is small enough and has a single function. It can be packaged, deployed, upgraded, rolled back, and elastically scaled independently without relying on other services to achieve local autonomy.

4.2 Differences between Microservices and SOA Architecture

1) Service splitting granularity: SOA first solves the service of heterogeneous applications; microservices emphasize that service splitting is as small as possible, and it is best to say independent principle services

2)服务依赖:传统的SOA服务由于需要重用已有的资产,存在大量的服务间依赖,微服务设计理念说服务自治、功能单一,避免依赖其他服务产品的耦合带来更高的复杂度

3)服务规模:传统的SOA服务粒度比较大;微服务强调尽可能拆分,同时很多服务会独立部署,导致服务规模急剧膨胀,对服务治理和运维带来新的挑战

4)架构差异:微服务化后,服务数量的激增会引起架构质量属性的变化,为了保证高性能低时延,需要高性能的分布式服务框架保障微服务架构的实施

5)服务治理:传统基于SOA Governance的静态治理转型为服务运行态微治理、实时生效

6)敏捷交付:服务由小研发团队负责微服务设计、开发、测试、部署、线上治理、灰度发布和下线,运维整个生命周期支撑,实现真正的Devops。0

 

 

 

http://blog.csdn.net/u014389822/article/details/51843205

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=326711992&siteId=291194637
Recommended