What Is CSE?

Cloud Service Engine (CSE) is cloud middleware for microservice applications. It provides users with high-performance and high-resilience enterprise-class cloud service capabilities, such as registry and discovery, configuration management, and service governance. Furthermore, it is seamlessly compatible with open-source ecosystems such as Spring Cloud, ServiceComb, and Dubbo. Users can use other cloud services to quickly build a cloud-native microservice system to implement quick development and high O&M of microservice applications.

Features:

Compatible with mainstream technologies in the open-source community
- Open-source frameworks such as Spring Cloud and Dubbo
- Access to CSE without code modification
- Mainstream open-source registry/configuration center
Unified service governance platform
- Multi-framework, multi-technology stack, and multi-language applications
- Interconnection, unified governance, and smooth evolution

Nacos Engine

CSE Nacos is compatible with open-source Nacos and Eureka clients. It provides registry and discovery, dynamic configuration management, access permission control, and observability. It can be used to build highly available and easy-to-manage microservice middleware.

ServiceComb Engine

CSE ServiceComb engines are developed based on the Apache ServiceComb open-source ecosystem and provide a one-stop microservice platform. You can use Java-Chassis SDK, SpringCloudHuawei SDK, or non-intrusive Sermant Java Agent (standard Spring Cloud and Dubbo frameworks supported) to access the platform. After accessing the platform, you can easily use functions such as service contract, service governance, dark launch, service governance, service monitoring, configuration management, and access control, practice API-first development, and build secure, high-performance, and stable microservice applications. For details about Apache ServiceComb Service Center, see the following:

ServiceComb engine has two versions: 1.x and 2.x.

ServiceComb 2.x engines are commercial engines that manage large-scale microservice applications. You can select different engine specifications based on service requirements, and these specifications cannot be changed once engines are created. Exclusive engines are exclusively used; therefore, the performance is not affected by other tenants.

Compared with ServiceComb engine 1.x, the underlying architecture, functions, security, and performance of ServiceComb engine 2.x are upgraded, providing an independent service registry and discovery center and configuration center, and supports custom service scenarios and governance. Table 1 lists features supported in CSE 1.0 and CSE 2.0.

**Table 1** Comparison between ServiceComb engine 2.x and ServiceComb engine 1.x
Feature	Sub-feature		2.x	1.x	Remarks
Engine management	Security	Security authentication	√	√	-
Engine management	Reliability	3-AZ high reliability	√	√	-
Microservice management	Basic capability	Registry and discovery	√	√	-
		Multi-frame access	√	√	Supports Spring Cloud and ServiceComb Java Chassis.
		Automatic clear of versions without instances	√	x	The latest three microservice versions are retained for version 2.3.7 and later, and the versions without instances are automatically cleared.
	Performance	Millisecond-level push of instance changes	√	√	-
Configuration management	Basic capability	Management and configuration	√	√	-
		Diversified configuration formats	√	Only text is supported.	2.x supports YAML, JSON, TEXT, Properties, INI and XML.
		Import and export	√	√	2.x supports configuration import of the same policy.
	Advanced features	History version management	√	x	-
		Version comparison	√	x	-
		Fast rollback	√	x	-
		Configuration labels	√	x	-
	Performance	Second-level delivery	√	x	-
Microservice governance	Scenario-based service governance	Custom service scenario	√	x	-
		Matching rule based on the request method	√	x	-
		Matching rule based on the request path	√	x	-
		Matching rule based on request headers	√	x	-
	Governance policy: rate limiting	Token bucket rate limiting on the server	√	√	-
	Governance policy: retry	The client performs retry to ensure the availability, fault tolerance, and consistency of user services.	√	√	-
	Governance policy: circuit breaker	The server breaks faulty services to prevent large-scale faults.	√	√	-
	Governance policy: repository isolation	The server controls the request concurrency capability based on the semaphore.	√	x	-
Development tool	Local lightweight engine	One-click local startup, facilitating offline microservice development	√	√	-