Ease Service Documentation

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 12
    • 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.