云原生开发框架

1. Product Principles

Ease Service makes the adoption of Cloud Native architecture highly easy, automatic, and productive for enterprises. It is targeting to eliminate the barriers & difficulties of Cloud Native based development and operation challenges, who need the fast evolution of online services to win competitions without the pain of increasing complicity costs, no matter what the organization sizes and IT skill levels are.

We have the following product Principles:

  • Service Centric. Service is the first class citizen, everything would be designed and developed based on service.

  • Build for Open & Standard . Following the industrial standard, community best practice, and reuse the Open Source software. Such as: Spring Cloud etc.

  • Deliver at Enterprise Level. There are big gaps between open source and enterprise level software. the Enterprise means:

    • Observability. The state, statistics, metrics, and logs for all service, components and middle-wares are monitoring and visual well.
    • Governance. It engages developer and operation engineer for effectively controlling and managing the risk, value, and cost.
    • High Availability. We need make sure all of the services, components and middle-ware can be works together to achieve the goal, not just some of them.
    • Enterprise Solution. must provide the enterprise solution, such as: canary deployment, high concurrency business campaign, fault recovery, service scheduling ... etc.

2. Design Principles

Ease Service is carefully designed to implement rich features around six core high-level functionalities:

  • Support the Multiple Forms. it can be delivered and installed in the production environment either as SDK or Service Mesh, depending on customer's requirements, standards, and solution scopes.

  • Observability & Tracing . Service observability & Tracing the very important for Cloud Native architecture. Not only monitoring the performance, throughput, latency, error rate and other statistics data for all service and middle-ware. Tracing the request among them also is very important. Ease Servcie only using the tracing techniques base-on Google Dapper papers, such as: Open Zipkin, Open Tracing, etc. (Note: SkyWalking does not follow the Google Dapper)

  • Integrated Service Governance Technology. The service governance includes the following functions or components.

    • Service Registry , supporting likes Eureka, Consul, Etcd, Zookeeper etc.
    • Configuration Management , supporting likes Apollo, Spring Cloud Config etc.
    • Service Proxy , supporting the Zuul, Envory or Spring Cloud Gateway etc.
    • Resilience Fault Tolerant, supporting the rate-limit, circuit breaker, retry, fallback etc.
    • Health Checking, monitoring the service health by its throughput, latency and errors.
  • Standardized Development . It's very important for an organization use a standard way to develop a service. Ease Service provides the following standard ways:

    • Remote Procedure Call, using the standard HTTP/2 for remote RPC.
    • Async Call, an easier way to make async call.
    • Logging, the log must be same format, and needs the tracing id.
    • Exception, all of the exception must be align with HTTP status code.
    • Middle-ware Adapter, it could adapt the same usage middle-ware, such as, cache,queue, etc.
    • API Documentation , integrates the Swagger API model to automatically generate API documents.

3. Features

Here just list the major features.

3.1 Basic

The Ease Service currently only support Java.

  • JDK 1.8+
  • Spring boot 2.2.1
  • HTTP/1.1
  • HTTP/2.0
  • gRPC
3.2 Supported Middle-wares

The Ease Service currently is based on the following Open Source softwares.

  • Service Discovery/Register.

    • Eureka 1.9+
    • Consul 1.6+
    • Zookeeper 3.0+
    • ETCD 3.0+
  • Configuration Management

    • Apollo
    • Spring Cloud Config
  • Service Proxy

    • Zuul 1/2
    • Spring Cloud Gateway
    • Envoy
  • Queue

    • RabbitMQ 3.0+
    • Kafka 2.0+
  • Cache

    • Redis
  • DataBase

    • MySQL 5.5+
3.3 Service Governance
  • Service Category. An well organized category can be easy to explorer all of the services.

    • The management of service instances.
    • The management of service category.
    • The version and configuration management.
  • Resilient Fault Tolerant. Supporting rate-limit, circuit breaker, retry, fallback etc

    • The Resilient policy and configuration management.
    • The Switch to enable and disable the resilient function.
  • Canary Deployment. The whole architecture traffic scheduling for canary deployment.

    • the canary service tags management
    • the canary configuration
  • Health Check . calculate the Apdex base on throughput, latency and error rate.

  • Metrics & Logs Collection . collecting the running data. Note: All of the data would be bound with service name.

    • Tracing logs. the request tracing logs collection

    • *Metrics.

      • Application Level - JVM, JDBC, HTTP request throughput, response time, error rate, etc.
      • Platform Level - The request for other middle-wares, such as: Service Gateway, Kafka, Redis, RabbitMQ, MySQL etc.
      • OS Level - CPU, Memory, IO etc.
3.4 Standardized Development
  • Declaration RPC. An Declaration RPC framework.
  • Standardized Logging. Make sure all of Service has same logging formation and the mandatory log fields, such as: process id, timestamp, trace id, etc.
  • Exception Handling. make sure the major exception can be aligned with the HTTP status code.
  • SWagger API Directory. Putting all of the API document in one place, so that the everyone can understand other department in the whole organization.
3.5 Others
  • Permission Management. The Role based permission management.

    • Role, Resource and Permission management.
    • Approval and Audit.
    • Enterprises LDAP integration.
  • Ease service mechanism . Ease Service achieves better service governance in two different ways, Intrusive/None-Intrusive.

    • Instrusive: Using SDK, requires code modification, less performance affected.
    • None-Instrusive: Using JavaAgent+Sidecar, no code modification, bring more complex operationis.
相关推荐
这个DBA有点耶36 分钟前
分布式数据库到底该不该上?从判断标准到架构选型的实战思考
数据库·架构·dba
01_ice1 小时前
MySQL库和表的操作
数据库·mysql
布莱克6052 小时前
数据库索引分类:数据结构、物理存储与逻辑角度详解
数据结构·数据库
SelectDB2 小时前
DeepSeek Harness 接入 Litefuse:完善 Agent 可观测与评估能力
数据库
这个DBA有点耶3 小时前
从库延迟的“二次放大”效应:一次大事务,拖垮整个读写分离
数据库·mysql·架构
LearnYard3 小时前
自然语言驱动的数据图表生成:几款工具功能对比实践
数据库·百度·powerpoint
一个有温度的技术博主4 小时前
MySQL 三大日志协同机制:redo log、undo log 与 binlog 的联合运作
数据库·mysql·oracle
ltl4 小时前
ClickHouse 与 DuckDB 选型:不是同一类列存
数据库
ltl4 小时前
RocksDB WAL 与 WriteBatch:持久化与原子批写
数据库
ltl4 小时前
流批一体与增量视图:Materialize、RisingWave 与 DBSP
数据库