当前位置:网站首页>Unscrambling 2021 of service grid: bid farewell to the "great leap forward" of architecture, and a hundred schools of thought contend for the technological ecology

Unscrambling 2021 of service grid: bid farewell to the "great leap forward" of architecture, and a hundred schools of thought contend for the technological ecology

2022-06-12 02:31:00 Deep learning and python

author | Peifei

edit | Cai Fangfang

Service grid 2021,“ steady ” Word first . Whether it's native community development , Or industry practice , Are subject to “ Stable ” For the first meaning . Without the great leap forward architecture evolution in previous years 、 Function alternation , More practical 、 More landing industry exploration and practice ,2021 The service grid in is running from that year “ juvenile ”、“ Traffic star ”, Grow into real “ The powerful ”, Gradually enter the mature stage , By more industries 、 Accepted by enterprises and standardization organizations . This article will progress from the community 、 Practice landing 、 Industry standard 、 Review the development of service grid from the perspective of technology ecology 2021, Help readers understand the overall progress of the service grid in the past year , Model selection for enterprises 、 The landing service grid provides some references .

This article is about “2021 InfoQ Annual technical inventory and Outlook ” One of a series of articles .

Community progress : Stable and pragmatic

2021 year ,Istio The community will launch a version every three months :1.9,1.10,1.11,1.12. The stable release cycle shows Istio Community development has been normalized , It also provides convenience for enterprises to select the appropriate version . in general ,2021 year Istio The community has not released any significant structural adjustment or innovation capability , More on accessibility 、 Operation and maintenance 、API And provide better native support :

  • 1.9 —— Better to use Virtual machine integration (Beta)、 Request classification (Beta)、Kubernetes Service API Support (Alpha)、 Integration with external authorization systems (Experimental) etc. . Virtual machine integration continues 1.8 Version introduces intelligence DNS ( Solve the problem of cross environment service name resolution ) The post virtual machine access experience is continuously optimized , Further enhance the ability of service grid to manage non container environments .
  • 1.10 —— Kubernetes Resource discovery selector 、 Stable revision label 、Sidecar Network changes, etc . among Kubernetes The resource discovery selector can limit Istiod from Kubernetes Configuration set received and processed , coordination Sidecar CRD/API resources , Further optimized Istiod To Envoy The amount of configuration .
  • 1.11 —— CNI plug-in unit (Beta)、 External control plane (Beta)、 Gateway injection 、 Updates to revisions and tag deployments 、 Support Kubernetes Multi cluster services ( experimental ). among CNI plug-in unit It provides users with Kubernetes Replace in the environment istio-init The scheme of the container ( There is no need to be higher Kubernetes jurisdiction ); External control plane It can provide users with the grid control surface deployed in the control cluster ; Updates to revisions and tag deployments It allows users to perform grayscale Istio Own deployment 、 upgrade , Reduce Istio Own operation and maintenance risks .
  • 1.12 —— WebAssembly API、 telemetering API、Kubernetes Gateway API. It's increased WasmPlugin As WebAssembly API, improve Istio Use WebAssembly Experience of plug-in extension .

throughout 2021 year Istio Four versions released by the community , It's not hard to see. :

  1. No major architectural changes have been released 、 Innovation ability : The enterprise is in Istio There is no special threshold for version selection .
  2. Ease of access : Add virtual machines 、CNI plug-in unit 、WebAssembly And so on , Deploy environments for more complex businesses 、 More demanding container environments 、 The extension requirements of more languages provide native capability support .
  3. Improved operation and maintenance : Stable revision label 、 External control plane, etc , by Istio Own operation and maintenance 、 Multi cluster management and control provides better native support .
  4. API Standardization : Include WebAssembly API、Kubernetes Gateway API、Kubernetes Service API Support, etc , Whether it's Istio Oneself API Standardization of , Or right Kubernetes standard API Support for ,Istio Community in API Ongoing efforts in Standardization .

Practice landing : Industry extension

Service grid technology originated from large Internet companies (Google、IBM、Twitter/Buoyant), Most of the early applications of service grid technology were implemented by Internet companies : Internet companies rely on their profound technical skills and continuous investment , In recent years, it has completed the leap from initial exploration to large-scale production and application of service grid ; Small and medium-sized Internet companies are also keeping up with the big companies , Comply with the wave of cloud native technology , Completed the service grid “ First experience ”.2021 year , Enterprises in more industries began to try to implement the service grid .

Enterprise demands

On a large scale 、 High stability 、 Take the financial industry known for its strong security as an example , 2021 A number of large state-owned banks in China 、 Head joint stock bank 、 The infrastructure teams of leading securities companies have begun to introduce service grid technology , Conduct technical research 、 Platform building 、 Business trial . Here we combine in 2021 Several leading enterprises in the financial industry served in , And other public technical information , Summarizes the typical demands of financial industry enterprises for service grid technology .

1. Landing zero threshold

stay Microservices 2020 Annual resumption In the article , We have put forward “ Smooth floor support ” It is one of the two key elements for enterprises to implement the service grid . In the financial industry , This is particularly obvious . Service Grid Landing zero threshold , It is one of the core demands of the enterprise .

We have summarized the requirements for service grid to support the implementation of enterprises “ Three elements ” : Communication protocol , Registry Center , Deployment environment .

  • Communication protocol : Service communication protocols that service grid can support , The common ones are HTTP、gRPC、Dubbo etc. , In addition, there are private enterprises with industrial attributes RPC agreement ;
  • Registry Center : The service grid can manage the registry , Including common Eureka、Consul、Nacos、Zookeeper as well as Kubernetes (ETCD);
  • Deployment environment : Service grid can support the business deployment environment , Except for the natural cloud Kubernetes + Docker Outside , For the virtual machine where the legacy system is located 、 The physical machine , It also needs to be treated equally .

In the meet “ Three elements ” after , Service grid can achieve the goal of business implementation “ Pass line ”.

In addition, we found that , There are more problems in the financial industry “ Land Rover ”:

  • Strict environmental control : Deployment platform ( Containers 、 virtual machine 、 The physical machine ) And basic platform ( Microservices 、 middleware ) Belong to different teams , Due to the division of enterprise responsibilities 、 Financial compliance requirements and other factors , The implementation of the service grid has been affected by such factors as The network environment 、 Administrative authority 、 Financial regulation Wait for more restrictions ;
  • A complex inventory system : Most enterprises in the financial industry have a relatively complete distributed system , But there are also many complications 、 Heterogeneous outsourcing 、 Legacy system , Due to multiple development languages 、 Multiple communication protocols 、 Unable to modify code 、 There is no registration and discovery mechanism , Many systems cannot be managed in the existing systems , Become an enterprise distributed system “ Isolated island ”.

2. Architecture scenario matching

Compared with the traditional microservice framework, it focuses on Business scenarios covering service governance capabilities Different , Service grid focuses on solving the problem of enterprise architecture scenarios . In addition to realizing the micro service management and governance capabilities under the cloud native system , Coverage is also required Unified management of heterogeneous applications 、 Legacy system migration And other architecture scenarios , In a real sense, it solves the integrity problems existing after the microservicing of enterprises .

We have summarized the typical demands of financial industry enterprises in terms of architecture scenarios as follows :

  • Multi cluster 、 Management of multi machine room business : Including providing normal service discovery 、 call 、 government 、 Cross regional disaster recovery, etc ;
  • Existing monomer 、 Microservice architecture , Cloud native service grid architecture long term 、 smooth 、 Stable migration and evolution : In a business imperceptible way , From the existing architecture to the service grid architecture , Migration process service interworking 、 Manageable 、 Observable , And ensure high SLA.

The core value of

After the initial completion of service grid cognition , Enterprise users often send out soul torture : Why go to the service grid ? What is the value of a service grid ?

Generally speaking , The core value of Tongshi's service grid “ The standard answer ” yes :

  • The business does not need to be aware of microservice components : Microservice architecture support 、 Network communication 、 Governance and other related capabilities sink to the infrastructure layer , The business department does not need to invest special personnel to develop and maintain , It can effectively reduce the R & D and maintenance costs under the micro service architecture ;
  • Support multiple development languages 、 frame : Service Grids naturally do not restrict development languages 、 Development framework , Provide multilingual service governance capabilities ;
  • Zero cost for framework upgrade : Support framework hot upgrade , Reduce middleware and technology framework clients 、SDK Upgrade costs ;
  • The microservice system is uniformly managed 、 evolution : Cluster the stock of micro services 、 Legacy system 、 Unified management of outsourcing system and microservice system 、 evolution .

For different teams within the enterprise , The value emphasis of service grid will be different :

  • Infrastructure / Platform R & D team : Pay more attention to the services covered by the grid Architecture scenario
  • Multiple development languages 、 Frame independent , It can manage the access of various business applications ;
  • Zero cost for framework upgrade , No business restart or perception is required ;
  • The microservice system is uniformly managed 、 evolution , You can cluster existing microservices 、 Legacy system 、 Outsourcing system, etc “ Grasp ”, Unified management and evolution ;
  • Business R & D team : Pay more attention to the business scenarios covered by the service grid
  • One click access microservice governance complete set of governance 、 Monitoring capabilities , Such as fusing 、 Current limiting 、 Downgrade 、 Fault tolerance 、 fault injection 、 Indicator monitoring 、 Link tracking, etc ;
  • Legacy 、 Outsourcing system can be incorporated into unified management , Have the same governance 、 Monitoring capabilities , Interconnection with other business microservices ;
  • No need to be aware of microservice components , Business developers no longer need to learn 、 Research and maintain microservice related technologies and frameworks .

Facing the challenge

Even if Istio The version is stable , Many Internet companies have also successfully completed the implementation of service grid , More industry enterprises are still facing challenges when landing on the service grid .

1. technical : Zero threshold access is not easy

From a technical point of view , Realization “ Zero threshold ” There are three challenges :

  • Communication protocol extension —— As an enterprise landing service grid “ Three elements ” first , A proxy that implements communication protocols 、 analysis 、 government 、 The full set of observable and other capabilities is a huge project , Especially for those who design away from HTTP、gRPC And so on RPC agreement ( It is particularly common in the financial industry ), Need to have a clever and complete extension mechanism to implement .
  • Custom plug-in extensions —— Most developers cannot write directly Envoy C++ Extension code ,Envoy Provided by the native Lua The language expansion ability is weak , High hopes of the community WASM(WebAssembly) In terms of performance, there is still a long way to go before production , There needs to be something really useful and productive Envoy Custom plug-in extension mechanism .
  • virtual machine / Physical environment management —— Even if Istio The community has been improving the virtual machines of the service grid / Physical environment management experience , Various public cloud vendors also provide corresponding services “ Residual blood version ” Ability , But the business deployed in non container is always like “ Two wait for a citizen ” equally —— It is difficult to obtain service grid capabilities that are equivalent to and equivalent to the deployment business in a container environment , Need to be more complete 、 More compatible non container environments Sidecar management 、 Traffic interception and other landing schemes .

2. Scene face : It is not easy to cover complex scenes

Businesses in the financial industry often operate in various environments 、 Deploy O & m under specification constraints , Coupled with the complexity of the business system itself , The stock of 、 Legacy 、 The combination of external production system exists , The service grid landing in the financial industry naturally has the challenge of scene coverage :

  • Multiple clusters of services 、 Multi-machine room deployment , Cross cluster 、 Interconnection of cross machine room calls 、 Unified governance 、 Abnormal disaster recovery , Various high availability guarantees, etc , All require the service grid system to have adaptability ;
  • Smooth evolution of business architecture , From the existing monomer 、 Microservice architecture , Gradually migrate to cloud native service grid architecture , Contains a microservice framework 、 Service grid, etc “ diachronic ” Long term coexistence of technology stacks 、 Service discovery 、 Mutual visits 、 government 、 observation , The ability to adapt to the business architecture migration scenario in a real sense is required SLA guarantee .

Industry standard : Set sail

Progress of service grid technology in community 、 After the practice is gradually stabilized , The corresponding industry standards and standard platforms are also natural , Set sail .

ICT Institute standards

2021 year 7 month , Sponsored by China information and Communication Research Institute 2021 At the trusted cloud Conference ,《 Service grid technology capability requirements 》 Standard officially released , Ali 、 NetEase 、 byte 、Flomesh Four enterprises passed the first batch of evaluation , Got the highest level of service grid evaluation . Interestingly , The first batch of four enterprises approved can be said to be major cloud computing manufacturers 、 Old Internet companies 、 New Internet company 、 A typical representative of a technology-based start-up company , This also reflects the importance that various enterprises attach to promoting service grid technology standards and implementation .

Standard platform

stay 2021 year , The service grid standard platform provided by cloud computing manufacturers is gradually improving and maturing , Enterprises can choose the standard platform on demand , Or build a service grid with manufacturers .

There are slight differences in the types of standard platforms provided by different manufacturers :

  • Native Istio resources + Public cloud infrastructure + Ecological integration : Focus on the original Istio Compatibility with and integration with the existing ecosystem of the public cloud ;
  • Native Istio platform + Privatization deployment + Tripartite Integration : be based on Istio Expansion and enhancement , Shield native Istio complexity , Focus on the unified management and control of the microservice system 、 government , And the adaptation and compatibility to the environment of enterprise privatization 、 Integrate ;
  • Self research service grid partial system or whole system : Unlimited and Istio Open source community , The weak points of the open source service grid are more targeted .

Different platforms have their own applicable scenarios and strengths , Enterprises can choose by themselves according to their own conditions .

Technology of ecological : Schools of thought contend

Service grid in 2021 In, it entered a stable period , Service grid technology ecology is also in full bloom in this year .

Open source project

stay 2021 year , a large number Istio Related excellent projects are open source , Around ease of use 、 Extensibility 、 Enhanced operation and maintenance Istio:

  • Slime: be based on Istio Intelligent service grid manager , by Istio An intrusion free management plane is added .2021 year 1 It is open source by Netease .
  • GetMesh:Istio Integration and command line management tools , Can be used for Istio Multi version management .2021 year 2 Month by month Tetrate Open source .
  • Aeraki: management Istio Any seven layer load , Provide multi protocol extension support for service grid .2021 year 3 This month, it was opened by Tencent .
  • Layotto: Cloud native application runtime , Can be used as Istio The data plane of .2021 year 6 Month is open source by ant .
  • Hango Gateway: be based on Envoy and Istio Built API gateway , Natural compatibility Istio, Provide native high performance and rich agent capabilities .2021 year 8 It is open source by Netease .

The emergence of many service grid ecological open source projects , It confirms the vitality of the service grid field .

Multiple runtime

And service grid will sink the microservice governance capability to the infrastructure layer (Sidecar) Similar thinking , Multiple runtime (Multi-Runtime) stay 2020 Year by year Bilgin Ibryam Put forward , the Sidecar Various forms of the model are summarized and sublimated . The characteristics of multi runtime can be summarized as follows :

  • Ability : Provide broader distributed capabilities than service grid , Such as middleware agent 、 news pub/sub etc. ;
  • Deploy : Can be related to business 1:1(per-pod) or 1:N(per-node) Corresponding , On demand deployment in a variety of environments , And carry out component combination ;
  • Interaction : And application through standards API communicate , Do not emphasize that the business is non intrusive , There will be bearing standards in the application API Of SDK.

The typical multi runtime open source framework is open source by Microsoft Dapr( Distributed Application Runtime), Its presence 2021 The year ushered in the landmark 1.0 edition , And enter CNCF Sandbox Incubate , It is still developing at a high speed .

From the perspective of landing practice , Multiple runtime in 2021 It has shown a good potential and development trend :

  • The concept is advanced , It may be the future trend of distributed architecture ;
  • Leading by big factories , The community is growing rapidly , A number of large factories have entered the Bureau for exploration ;
  • The overall maturity is not high , In point-to-point service communication governance 、 Capability integrity 、API The stability and other aspects are still insufficient ;
  • It can be combined with existing technologies such as service grid Ecological integration , Make up the short board .

eBPF

eBPF The emergence of technology makes it possible to Linux It is possible for the kernel to program and run sandboxed programs , And there is no need to change the kernel source code or load kernel modules . This allows developers to enhance the observability of the system from the kernel 、 Optimize the network and its security . In the field of service grid ,eBPF It can be used for Sidecar Network acceleration , And it can be observed from the bottom Kernel message queue 、 Task queue 、 Network packet information 、 network connections And so on .

stay 2021 year ,Cilium(eBPF Open source framework ) Put forward to use eBPF replace Sidecar Implement kernel level service grid ( Data side agent ) Conception , To solve the problem of independence Sidecar Deployment resource consumption 、 Delay performance loss, etc , Achieve real traffic management 、 The observation capacity sinks to the infrastructure layer . however ,Cilium This bold idea was soon received from “ Tradition ” Service grid camp “ counterattack ”, The reasons include eBPF There are many limitations to the ability to implement service proxies 、 The operation is complicated 、 The protocol processing complexity is high 、 The kernel version has dependencies and so on .

Anyway ,eBPF It is a new trend to integrate technology into service grid ecology , Even if it can't be realized Sidecar The perfect replacement of ,eBPF Can also be As Sidecar A powerful complement to , Make the two blend on the traffic link .

Proxyless

At the beginning of its birth, service grid has been independent Sidecar Proxy Agent in charge of traffic 、 government 、 observation , Service grid implementation frameworks are also independent by default Proxy Way to organize data plane capabilities , And with the application process Traditional microservice frameworks draw a clear line , Talk about the pros and cons , Seems to be Proxy Patterns are the standard patterns for serving the grid data plane . stay 2021 year , Application in process framework and independence Sidecar Proxy Between the “ Dimension wall ” Broken ,Proxyless Ideas are mentioned more and more .

WHY Proxyless( In essence, it is independent of the service grid Sidecar Proxy Mode “ Disadvantages ” And come ):

  • Performance issues : Independent Proxy Additional deployment resource overhead and delay performance overhead ;
  • Traffic interception : Independent Proxy Most of the traffic interception needs cooperation IPTables Technology , Administrative permissions are required , Complex logic , It is not easy to remove obstacles ;
  • Governance granularity : Independent Proxy Working outside the application process , And no state , Cannot apply in-process programs 、 Methods control and observation .

WHAT Proxyless( It can provide capability supplement for various distributed scenarios ):

  • Service grid optimization : Provide fine-grained governance within the application 、 Monitoring and traffic interception capability ;
  • Multiple runtime operations : Provide standards within the application SDK, Provide the business with the operation interface for infrastructure resources ;
  • Capacity continues to sink : Implement traffic processing in the operating system kernel 、 government 、 observation .

HOW Proxyless( Several common implementation methods ):

  • frame / SDK: Classic usage , Back to the past ;
  • No intrusion Agent: Non intrusive way to achieve business code enhancement , The principle can refer to our previous From service framework to service grid , Netease light boat dual engine multi-mode service governance evolution practice In the article “ Service Framework : No intrusion Agent Service governance ” Part introduction ;
  • Native RPC Support : The new version gRPC Directly provide governance functions , It also supports the standard of direct docking control plane xDS agreement ;
  • eBPF: stay Linux The kernel handles traffic 、 government 、 observation .

From the perspective of architecture evolution ,Proxyless Yes “ Against the Current ” Suspicion of development . however , From a pragmatic perspective ,Proxyless by Proxy Bring the ability to supplement , It may better help enterprises complete the gradual migration from traditional architecture to cloud native architecture .

Future outlook

For service grid 2021 This is the end of our second offer , For the future of service grid , We are full of confidence . At the end of this article , Give our outlook for the future of service grid :

Zero threshold

With the gradual refinement and maturity of service grid technology , And the experience accumulated in more and more industries , The technical and scenario challenges will eventually be overcome , The landing threshold of service grid will gradually become zero .

Standardization

The technical capabilities and scenario coverage of service grid are highly abstracted and generalized , Service grid platform / Products will also be highly standardized , Enterprises choose the service grid platform / The product will be easier .

Comprehensive unification

With Envoy、Istio The service grid technology represented by will help to realize the unification of related software fields , Like more L7 The traffic agent will Envoy Build for the core , Between the data plane and the control plane xDS Protocol interaction, etc . The global unified governance of distributed systems that enterprise architects want to achieve will no longer be an extravagant hope .

Ecological integration :Proxyless + Proxy + eBPF + Multiple runtime

There will be no opposition between different ecosystems of the service grid , In the end “ Pragmatic ” To form “ Together ”, Win win : On the traffic link Proxyless -> Proxy -> eBPF Collaboration , Complementary capabilities ; The capability short boards existing under multiple runtime can integrate the mature capabilities of the service grid , Accelerate your own development .

Reference material ( Special thanks to many practitioners and sharers in the field of service grid ):

From service framework to service grid , Netease light boat dual engine multi-mode service governance evolution practice :https://www.infoq.cn/article/KNp1ibj40vS8IIZCizMW

Interpretation of micro services 2020: The frame is on the left and the grid is on the right , Where is the micro service path in the cloud native era :https://www.infoq.cn/article/4Zog2lMBqKjAeMTc8Add

The traffic entrance of cloud primary era :Envoy Gateway:https://www.infoq.cn/article/SF5sl4IlUtUxuED3Musl

Istio 1.9 Release —— Focus on Improvement Istio Of Day2 operation :https://mp.weixin.qq.com/s/E7iwBF6hhPm5aTukTlTCMg

Istio 1.10 Release and official website revision :https://mp.weixin.qq.com/s/Lq6zF90FR-ohT9ON-88Z_Q

Istio 1.11 Release :https://mp.weixin.qq.com/s/QkLUFOCQz2AWt2En-G-VQg

Istio 1.12 Release :https://mp.weixin.qq.com/s/Q52IQrXxxHEn2c8rkAVTgA

be based on gRPC and Istio No Sidecar Proxy service grid :https://mp.weixin.qq.com/s/aYwo2criOotqNp8lD39QAA

all 2021 Years. , For service grid , What the community is talking about :https://mp.weixin.qq.com/s/ZDDC4YAebbdws8Md9zCrqQ

Dapr v1.0 expectation : from servicemesh To cloud native :https://skyao.io/talk/202103-dapr-from-servicemesh-to-cloudnative

a farewell Sidecar—— Use EBPF Unlock the kernel level service grid :https://mp.weixin.qq.com/s/W9NySdKnxuQ6S917QQn3PA

translation : The service grid will use eBPF ? Yes , but Envoy The agent will continue to exist :https://mp.weixin.qq.com/s/iZYXPec7Lh0fhflA42d8gA

The authors introduce :

Peifei , Netease Shufan senior technical expert 、 Senior architect .10 Years of experience in enterprise platform architecture and development , Currently, he is mainly responsible for Netease Shufan light boat micro service team , Focus on the research and implementation of enterprise microservice architecture and cloud native technology . Lead the team to complete the canoe service grid 、 Microservice framework 、API Gateway and other projects in Netease group landing and commercial product output , And led the construction of Slime、Hango And other cloud native open source projects .

原网站

版权声明
本文为[Deep learning and python]所创,转载请带上原文链接,感谢
https://yzsam.com/2022/03/202203011145390974.html