About Me
My name is Cong Guoqing. I graduated from Harbin Institute of Technology with a
bachelor's degree and majored in software engineering with a master's degree in
Shandong University.
In 2021, I had an internship at SenseTime. As a software development engineer,
I participated in building Cosine open source community, and I am familiar with
git collaborative development.
As a Java programmer, Dubbo is equivalent to Spring in the field of business
development, and I often use Dubbo in business. This opportunity would like to
participate in the integration of Dubbo and cloud native ,and I could
contribute to the development of Dubbo.
I love programming and can commit 40 hours a week. When personal work conflicts
with GSoC, I try to balance the two and quickly return to GSoC when the work at
hand is completed. During the holidays, I will devote myself to the open source
work and ensure that I can finish the task on time. Please rest assured that my
tutor and the organization can rest assured.
Personal Technology Stack
Java(proficient), Spring WebFlux(familiar), SpringBoot(familiar), Spring Cloud
Alibaba(familiar), Typescript+React(proficient), Go(know).
Proficient with Docker+Swam. Understand K8S operation mechanism.
The Project Design
1. Application startup
l Dubbo application process aligned with Sidecar lifecycle
○ Ensure that Sidecar detects that the Endpoint is healthy after normal startup.
Preliminary solution: The Dubbo application connects to Sidecar and sends POST
/HealthCheck/OK
○ Operating state: Check the health check to ensure survival
○ If the Dubbo application goes offline gracefully, Sidecar must be able to
sense that the Endpoint is offline.
Preliminary solution: Send POST /HealthCheck /fail
l In the startup process, except for life cycle alignment, other major actions
need to be reduced, which has little impact on the main mesh process.
2. Health check
Run state, which verifies whether the Dubbo application is healthy through an
envoy health check. At present, Triple protocol realizes Health check based on
the Health interface of gRPC. You need to support the Envoy'S HTTP health check
Filter.
3. The service registry
The most mature of the registries supported in ISTIO is Kubernetes, and the
Kubernetes Registry is recommended for phase one. At present, there is an
implementation of Kubernetes Registry, which is mainly stored in Kubernetes
ETCD in the form of CRD:
l Metadata content is stored in annotations.
l Application name corresponds to Kubernetes Service model.
l Hosts: {IDL service name}.{namespace}.svc.cluster.local But for Kubernetes
service registration is still missing a lot of content, application level
service registration needs to consider the interface name and application name
mapping relationship, in addition to the custom label, namespace, etc., need to
increase the external configuration.
4. Service discovery
The problem of service discovery is how to trigger service discovery on the
data side. The current operation of Pilot is to discover the full Service and
Workload data from Kubernetes on the first cluster startup, and send the
Service discovery data to the Pilot Agent instance via xDS, and then push it
increments. In the service discovery phase, the Dubbo application only connects
to the Envoy and does not initiate any subscriptions.
5. The service call
The interconnection of load balancing policies is performed by Sidecar instead
of Dubbo.
Store the routing rules to Kubernetes API Server and register Kubernetes CRD
resources as the storage of routing rules. Routing rules are delivered to
Sidecar through RDS, and Sidecar acts as a service route.
Schedule
5.21-7.1: Discuss the overall idea with the supervisor, write design documents,
and plan the overall scheme of the project.
7.2-7.23: The first stage of development, firstly develop the health check
function of the application startup part, this stage is mainly to get familiar
with the code.
7.24-9.4: The second phase of development, the development of health inspection
and service registration, so that Dubbo can better use K8S as the registry,
changing the original registry.
9.5-10.1: Phase 3 development, revamping Dubbo service discovery.
10.1-11.1: The fourth stage of development, Sidecar access, thin SDK closure
and integration testing.
11.2-11.12: Sorted out projects and wrote defense reports.
Personal Project Experience
1. Qing Gateway—Design and implementation of high-performance responsive gateway
The Qing Gateway is a high-performance, multi-protocol, scalable, distributed,
responsive API Gateway with an interactive management platform interface. The
single-machine Gateway can withstand 10W QPS flow, the Gateway processing loss
is only 1-3ms, and the performance is as good as that of Spring Cloud Gateway.
Compatible with mainstream microservice tools: Nacos, Redis, MySQL. Based on
the SPI mechanism, hot swap is supported. Users can customize the development
to meet the current and future requirements of users in various scenarios.
l Multiple design patterns: chain of responsibility, singleton, factory, and
listener are used to enhance code readability, maintainability, and
extensibility.
l Based on NIO synchronous non-blocking, responsive mode, increased gateway
throughput.
l The routing rules, service instance data and other information are cached in
the JVM memory, so that the loss of the gateway to process the request in the
early stage is very low, only 1-3ms.
l For log processing and QPS collection, block queue and merge processing are
adopted to reduce network I/O times and greatly improve performance.
l The idea of plug-in enhances the user's custom expansibility.
2. Implementation of non-intrusive edge computing framework based on cloud edge
collaboration
The edge computing platform was built based on Swam + Docker + Zuul +
SpringCloud + Spring Batch.
l Zuul serves as a traffic entry point and its dynamic routing rules are
intelligently changed by Swam monitoring the current online service.
l Spring Batch is used for edge and central database synchronization.
l The core of the whole system is that the background service will monitor the
server of the Swam Master node, and then Master the operation status of the
circle Master node and the central node. When any of the nodes go down, the
decision engine will decide the implementation of the policy. If the circle
Master node goes down, its service and data will be migrated to the central
node.
| |
丛国庆
|
|
[email protected]
|
