Opensergo is about to release v1alpha1, which will enrich the service governance capabilities of the full link heterogeneous architecture

author ： Where to stay & Bobby

OpenSergo  What is it?

In the traditional microservice Architecture , We divide the roles in service invocation into four parts ： Service providers 、 Serving consumers 、 Registry Center 、 monitor . With the continuous evolution of distributed service architecture, there are many complex stability and ease of use problems , Single monitoring can no longer meet the evolution of the architecture . In the modern microservice Architecture , We need some means to deal with the complex microservice architecture “ government ”. Microservice governance is through full link grayscale 、 Lossless online and offline 、 Flow control degradation 、 Abnormal traffic scheduling 、 Database governance and other technical means to reduce or even avoid the stability problems encountered in the process of publishing and managing large-scale applications , Manage the components in the field of microservices . Service providers 、 consumer 、 Registry Center 、 Service governance , It constitutes several important links in modern microservice architecture .

Within the enterprise , There are often different languages 、 Microservices with different communication protocols , This isomerized architecture will lead to the process of governing micro Services , Business Developer 、 Architects cannot govern and control all services in a unified way , And this kind of isomerism will generate more pain points ：

• The industry has no clear understanding of the capabilities and boundaries of service governance , The concept of service governance defined by each enterprise is inconsistent , Resulting in high understanding and communication costs .

• There are many open source microservice frameworks , Lack of some standardized conventions on service governance . for example ,Spring Cloud  Microservice interfaces and interfaces defined in  Dubbo  There is no way for the interfaces defined in to communicate with each other , adopt  Dubbo  and  Istio  There is no way to manage the managed microservices in a unified way . Developers cannot configure different frameworks in a unified way 、 Unified management and control of services in different languages .

• Lack of real business orientation 、 Abstractions and standards that can reduce the burden of cognition . What developers really want may be simple 、 Specify the calling relationship and configuration rules between services . But now for business developers , It is not only necessary to understand the deployment architecture of different microservice frameworks , We should also understand the concepts and capabilities of different service governance methods , The cognitive cost is great .

Based on the above pain points , Alibaba is in  2022  year  1  The month begins with  bilibili、 Vendors such as byte discuss how to standardize and popularize service governance , Thus co sponsored  OpenSergo  project .OpenSergo  It's a set of openness 、 General purpose 、 Distributed service oriented architecture 、 Service governance standards covering the whole link isomerization ecosystem , Form a general standard for service governance based on the service governance scenarios and practices in the industry .

OpenSergo  The most important feature of the game is

With a unified set of configurations /DSL/ The agreement defines the service governance rules , Multilingual isomerization oriented architecture , Achieve full link ecological coverage .

  No matter the language of microservices is  Java, Go, Node.js  Or other languages , Whether it's standard microservices or  Mesh  Access , From gateway to microservice , From database to cache , From service registration discovery to configuration , Developers can use the same  OpenSergo CRD  The standard configuration provides unified governance and control for each layer , Instead of focusing on the frameworks 、 Differences in language , Reduce isomerization 、 The complexity of full link service governance and control .

OpenSergo  The standard is based on the practice and scenario abstraction of related fields in microservice governance , It covers the service meta information 、 Traffic management 、 Service fault tolerance 、 database / Cache governance 、 Service registration found 、 Configuration governance and other key areas , It covers the complete life cycle of microservices （ From development state to test state , To release , And then to the running state ）. Whether we want to target  Spring Cloud + Dubbo  Service link configuration traffic gray isolation , I still hope for one  Go gRPC  Service flow control , I still hope that the database access for the service is slow  SQL  Call to automatically fuse , We can all use  OpenSergo spec  As defined in  CRD  Standard for unified configuration , There is no need to pay attention to the different declarative expressions of each framework  API  And incompatible configuration formats .

OpenSergo  Ecology consists of the following parts ：

• OpenSergo spec： Unified service agreement and  CRD  Standard definition

• OpenSergo  Multilingual  SDK： Provide uniform standards  CRD  Docking module , For the docking of various frame components  OpenSergo spec

• OpenSergo  Data side ： I.e. docking  OpenSergo spec  Frame components , Can pass  OpenSergo  Unified management in a standard way

• OpenSergo  Control surface ： Provide a unified console for service meta information query and traffic routing 、 Configuration of governance rules such as flow control .

We look forward to working with all communities to build , Connect more frameworks and components to  OpenSergo  In the ecological , Every framework is  OpenSergo  The data side of , Can pass  OpenSergo CRD  Conduct unified management and control .

that  OpenSergo  What exactly does the standard look like ？ We can use  OpenSergo  What are the standards to do ？ Let's introduce it with several examples .

OpenSergo  Standard introduction

OpenSergo  The project covers service meta information 、 Service registration found 、 Traffic management 、 Service fault tolerance 、 Database governance 、 Cache management and other fields . In our first version  v1alpha1  In the version , We provide   Service contract （ Metadata ）、 Traffic routing 、 Flow control degradation   In these areas  CRD  standard . Next, let's introduce the examples of traffic routing and flow control degradation .

Traffic routing

Traffic routing , As the name suggests, it refers to the traffic with certain attribute characteristics , Route to the specified destination . Traffic routing is an important part of traffic management , We can implement various scenarios based on traffic routing Standards , Such as full link gray 、 Release of canary 、 Disaster tolerant routing .

Traffic routing rules (v1alpha1)  It is divided into three parts ：

• Workload  Labeling rules  (WorkloadLabelRule)： Put a group  workload（ Such as  Kubernetes Deployment, Statefulset  Or a group  pod, Or some  JVM  process , Even a group  DB  example ） Label it accordingly

• Flow label rules  (TrafficLabelRule)： Traffic with certain attribute characteristics , Label it accordingly

• according to  Workload  Tag and traffic tag to do matching routing , Route the traffic with the specified label to the matching  workload  in

We take the widely used full link grayscale scene as an example . The full link grayscale passes through a series of traffic routing rules , Divide the same version of multiple services on the link into the same swimlane , So as to restrict the flow to flow only in the specified Lane , Realize the purpose of traffic isolation of the whole link .

The whole process can be summarized in the following figure , We use general  Workload  Labeling rules and flow labeling rules , To realize the gray scale capability of the complete service link in a unified standard way .

to  Workload  tagging ：

When we gray the new version , Usually there will be a separate environment , Separate deployment sets . We put a separate deployment set  gray  label （ The tag value can be customized ）, Tags will participate in specific traffic routing .

We can do it directly in  Kubernetes workload  Hit up  label  Tag binding , If in  Deployment  Put it on  traffic.opensergo.io/label: gray Labels represent grayscale . For some complex  workload  Marking scene （ Such as database instance 、 Cache instance tags ）, We can use  WorkloadLabelRule CRD  To mark . Example ：

apiVersion: traffic.opensergo.io/v1alpha1
kind: WorkloadLabelRule
metadata:
 name: gray-sts-label-rule
spec:
 workloadLabels: ['gray']
 selector:
 app: my-app-gray
 database: 'foo_db'


Mark the flow ：

Suppose you now need to gray the internal test users to the new homepage , Test user  uid=12345,UID  be located  X-User-Id header  in , Then you only need to configure the following  CRD  that will do ：

apiVersion: traffic.opensergo.io/v1alpha1
kind: TrafficLabelRule
metadata:
 name: my-traffic-label-rule
 labels:
 app: my-app
spec:
 selector:
 app: my-app
 trafficLabel: gray
 match:
 - condition: "==" #  Match expression
 type: header #  Match attribute types
 key: 'X-User-Id' #  Parameter name
 value: 12345 #  Parameter values
 - condition: "=="
 value: "/index"
 type: path


Through the above configuration , We can  path  by  /index, And  uid header  by  12345  Of  HTTP  Traffic , In the play  gray  mark , It means that this traffic is gray traffic .

Route by tag ：

In the specific routing process , Access  OpenSergo  The microservice framework of 、Service Mesh  Of  proxy  in , As long as it's done  OpenSergo  Standard and configure the above rules , Then you can identify the labels and  workload  The label of . belt  gray  The flow of tags will flow to  gray  In the instance group of the tag ; If there is no in the cluster  gray  Instance grouping （ That is, no  workload  With this label ）, By default  fallback  To instances without labels . Subsequent versions of the standard will provide a way to configure unmatched traffic .

The community is also constantly improving the standards related to traffic routing , And cooperate with various communities to build , Let more framework components support  OpenSergo  standard , So as to support unified traffic routing control .

Flow control degradation and fault tolerance

Flow control degradation and fault tolerance are also the key links in service traffic management , Take flow as the starting point , Through flow control 、 Fusing the drop 、 The flow is smooth 、 Adaptive overload protection and other means to ensure the stability of the service . stay  OpenSergo  in , We combine  Sentinel  And other frameworks to practice the flow control degradation and fault-tolerant extraction Standards  CRD. A fault tolerant governance rule  (FaultToleranceRule)  It consists of three parts ：

• Target:  For what kind of request

• Strategy:  Fault tolerance or control strategy , Such as flow control 、 Fuse 、 concurrency control 、 Adaptive overload protection 、 Outlier instance removal, etc

• FallbackAction:  After triggering  fallback  Behavior , Such as returning an error or status code

Whether it's  Java  still  Go  still  Mesh  service , Whether it's  HTTP  Request or  RPC  call , Or database  SQL  visit , We can all use this unified fault-tolerant governance rule  CRD  To configure fault-tolerant governance for each ring in the microservice architecture , To ensure the stability of our service link . As long as the microservice framework is adapted  OpenSergo, Through unification  CRD  Flow control degradation and other governance .

following  YAML CR  The rules defined in the example are for  path  by  /foo  Of  HTTP  request （ Identify with resource name ） A flow control strategy is configured , The overall situation does not exceed  10 QPS. When the policy is triggered , The rejected request will be based on the configured  fallback  return  429  Status code , The return information is  Blocked by Sentinel, At the same time return to  header  Add one  header,key  by  X-Sentinel-Limit, value  by  foo.

apiVersion: fault-tolerance.opensergo.io/v1alpha1
kind: RateLimitStrategy
metadata:
 name: rate-limit-foo
spec:
 metricType: RequestAmount
 limitMode: Global
 threshold: 10
 statDuration: "1s"
---
apiVersion: fault-tolerance.opensergo.io/v1alpha1
kind: HttpRequestFallbackAction
metadata:
 name: fallback-foo
spec:
 behavior: ReturnProvidedResponse
 behaviorDesc:
 #  After triggering policy control ,HTTP  Request returns  429  Status code , Carry the specified content and  header.
 responseStatusCode: 429
 responseContentBody: "Blocked by Sentinel"
 responseAdditionalHeaders:
 - key: X-Sentinel-Limit
 value: "foo"
---
apiVersion: fault-tolerance.opensergo.io/v1alpha1
kind: FaultToleranceRule
metadata:
 name: my-rule
 namespace: prod
 labels:
 app: my-app #  The name of the application where the rule configuration takes effect
spec:
 targets:
 - targetResourceName: '/foo'
 strategies: 
 - name: rate-limit-foo
 fallbackAction: fallback-foo


At the middleware developer summit , We announced  Sentinel 2.0  Comprehensive upgrading of traffic management .Sentinel 2.0  Relate native support to traffic governance  CRD  To configure , combination  Sentinel  The adaptation module of each frame provided , Give Way  Dubbo, Spring Cloud Alibaba, gRPC  etc. 20+ The framework can be seamlessly connected to  OpenSergo  In the ecological , Use unified  CRD  To configure traffic routing 、 Flow control degradation 、 Governance rules such as service fault tolerance .

Community Planning

Let heterogeneous microservices be governed by unified service protocols and configurations 、 Let more micro services be interconnected , Create more cloud native micro Services , yes  OpenSergo  The long-term development goal set at the beginning of its establishment .

In terms of standardization construction ,OpenSergo  The community will unite more open source communities and enterprises , In database governance 、 Cache governance 、 Service registration found 、 Standardize microservice governance capabilities at the level of configuration governance and other fields , Enable enterprises to use a common language to describe and govern their own micro service architecture , Let developers focus on business core values , So that the micro service framework can also be easily adopted by customers .

In community ecological construction ,OpenSergo  The community will gradually cover the gateway 、RPC、 database 、 Cache to service discovery 、 Service configuration and other distributed service links , By working with communities , So that all mainstream frameworks can use unified  OpenSergo spec  The ability to define and implement service governance , Developers don't need to pay attention to frameworks 、 The concept and implementation of the protocol are different , Reduce developer cross language 、 Cross framework 、 The control cost of cross protocol service governance .OpenSergo  The community will continue to work with  Kratos、CloudWeGo Kitex、Spring Cloud Alibaba、Dubbo  Wait for the community to cooperate , At the same time, it will also promote  Apache APISIX、Envoy/Istio、gRPC、Druid、ShardingSphere  Wait for more community cooperation , Put the standard into each frame . We also welcome more open source communities and enterprises to join  OpenSergo  Standards and ecological co construction .

In the construction of control surface ,OpenSergo  At present, it is building a joint community  OpenSergo Dashboard  As a unified service governance control surface , Through neutrality 、 General purpose  OpenSergo  Standard agreement , Let all microservice frameworks 、 All communication protocols can be governed by the same set of microservice portal .

Welcome to join

OpenSergo  Since its inception, it is a community project , adopt  Apache License 2.0  Open source agreement .OpenSergo  Is working with  Apache Dubbo, CloudWeGo Kitex ( byte ), Kratos (bilibili), Spring Cloud Alibaba, Apache APISIX  Wait for the community to cooperate , Jointly improve the design and implementation of service governance standards , Together  OpenSergo spec  Promote and implement into more micro service ecosystems . Follow up  OpenSergo  Formulation of service governance standards 、 On development , Also through public 、 transparent 、 Democratic way to set standards 、 Promote the implementation of . The community also passed  GitHub issue、Gitter、 Mailing list, 、 Community biweekly meetings and other mechanisms , Ensure that standards and implementation are jointly built through community collaboration . Welcome to discuss together through these forms 、 To build .

You are also welcome to join us  OpenSergo  Community nail group , Together, define the future of microservice governance ：

At the same time, we also provide  OpenSergo  Enterprise level products of microservice standard  MSE, Provide service governance 、 Flow control degradation 、 Register configuration center 、 Cloud native gateway 、 Core capabilities such as distributed transactions , Welcome to experience .

Related links ：

OpenSergo  Project website ：

https://opensergo.io/

OpenSergo spec:

https://github.com/opensergo/opensergo-specification

Alibaba cloud micro service engine  MSE,OpenSergo  Enterprise level implementation of ：

https://www.aliyun.com/product/aliware/mse

MSE  First purchase of professional edition of registration configuration center  9  A discount ,MSE  Full specification of cloud native gateway prepaid  9  A discount .

Click on

here

, Enjoy the discount ~