You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicecomb.apache.org by Eric Lee <er...@gmail.com> on 2017/12/19 08:45:49 UTC
refactor/rewrite service registry module in Java Chassis
Hi, all
We plan to refactor/rewrite the service registry module in Java Chassis. This
module is mainly responsible for the interaction between service center and
the microservices developed by Java Chassis, namely, client side
implementation for service registration and discovery. The analysis of this
module and what it supposed to be is mentioned below. Any questions or
suggestions are welcomed.
Background
The architecture of the service registry module in Java Chassis is as
follows.
However, it has the following problems:
-
Low level components access high level components frequently. The cyclic
relationships make the implementation complicated and introduce some
redundant access points.
-
Low level components should be stateless to be reused by high level
components. Introducing state into low level components makes it relies
heavily on the high level components, causing cyclic relationships.
-
Hard to integrate with third-party framework. It does not provide a
standalone client with cache capability inside. It also requires the
configurations should be loaded from dynamic properties.
Proposed Architecture
The above architecture is what the service registry module supposed to be
in my opinion. The low level components like ApiManager and UriManager are
stateless so they do not rely on high level components any more.
Relationships between components are clear and simple.
Tasks can be divided into the following parts:
There are two types of tasks:
-
Simple Task. Task that executes only once.
-
Period Task. Task that executes at every interval.
The result of task will convert to event and posts to the EventManager. Any
methods that subscribes that kind of event will be notified and execute the
corresponding response, e.g. update the cache.
Both the outside requests and chassis requests share the same interface of
Configuration, they can implement their own way to load configurations. The
difference between chassis requests and outside requests is that chassis
requests need to manage microservice informations of their own. Besides,
chassis requests also need to provide a compatible interface for requests
to use. There comes to the component RegistryUtils. It is responsible for
the following stuff:
-
Initialize service registry client with configurations.
-
Initialization of service center service, attach with a PullTask.
-
Initialization of service itself, attach with RegisterTask,
HeartbeatTask and WatchTask.
-
Provide wrapper method for service registry client.
The initialization process of service registry client is as follows:
If the auto discovery switch is on, it need to create a period task PullTask
to make the available service center services' information up to date.
Any requests to a new microservice will create a new entry in the service
registry client. Once we access the same microservice again, the client
will response with the cached version which reduces communication cost with
service center.
Let's checkout how the Microservice component works. Instances and its
versions are cached inside the microservice. To get an instance of a
specified id, all it needs to do is lookup the cache or create a query task
to update the cache. All interactions from Microservice to ApiManager are
done by the Task.
The ApiManager is designed to interact directly with service center as a
pure client with api inside only. Its structure is as follows:
Best Regards!Eric Lee
Re: refactor/rewrite service registry module in Java Chassis
Posted by Eric Lee <er...@gmail.com>.
Hi all,
The proposal has moved to the ServiceComb website, anyone can visit it at
http://servicecomb.io/docs/service-registry-refactor-proposal/ . The
content of the it will keep up to date during this discussion.
BTW, thanks to Willem's advice.
Best Regards!
Eric Lee
2017-12-19 17:31 GMT+08:00 Willem Jiang <wi...@gmail.com>:
> Hi Eric,
>
> You can put this document into the ServiceComb website as a proposal for
> refactoring the service center module.
> In this way we can keep the other people in the loop of latest updated
> design doc.
>
>
> Willem Jiang
>
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.iteye.com (Chinese)
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Tue, Dec 19, 2017 at 5:06 PM, Eric Lee <er...@gmail.com> wrote:
>
>> My bad, turns out the images are unable to show in some mailbox. The pdf
>> version is in the attachment.
>>
>> Best Regards!
>> Eric Lee
>>
>> 2017-12-19 16:45 GMT+08:00 Eric Lee <er...@gmail.com>:
>>
>>> Hi, all
>>>
>>> We plan to refactor/rewrite the service registry module in Java
>>> Chassis. This module is mainly responsible for the interaction between
>>> service center and the microservices developed by Java Chassis, namely,
>>> client side implementation for service registration and discovery. The
>>> analysis of this module and what it supposed to be is mentioned below. Any
>>> questions or suggestions are welcomed.
>>>
>>> Background
>>>
>>> The architecture of the service registry module in Java Chassis is as
>>> follows.
>>>
>>> However, it has the following problems:
>>>
>>> -
>>>
>>> Low level components access high level components frequently. The
>>> cyclic relationships make the implementation complicated and introduce some
>>> redundant access points.
>>> -
>>>
>>> Low level components should be stateless to be reused by high level
>>> components. Introducing state into low level components makes it relies
>>> heavily on the high level components, causing cyclic relationships.
>>> -
>>>
>>> Hard to integrate with third-party framework. It does not provide a
>>> standalone client with cache capability inside. It also requires the
>>> configurations should be loaded from dynamic properties.
>>>
>>> Proposed Architecture
>>>
>>>
>>>
>>>
>>> The above architecture is what the service registry module supposed to
>>> be in my opinion. The low level components like ApiManager and
>>> UriManager are stateless so they do not rely on high level components
>>> any more. Relationships between components are clear and simple.
>>>
>>> Tasks can be divided into the following parts:
>>>
>>>
>>>
>>>
>>> There are two types of tasks:
>>>
>>> -
>>>
>>> Simple Task. Task that executes only once.
>>> -
>>>
>>> Period Task. Task that executes at every interval.
>>>
>>> The result of task will convert to event and posts to the EventManager.
>>> Any methods that subscribes that kind of event will be notified and execute
>>> the corresponding response, e.g. update the cache.
>>>
>>> Both the outside requests and chassis requests share the same interface
>>> of Configuration, they can implement their own way to load configurations.
>>> The difference between chassis requests and outside requests is that
>>> chassis requests need to manage microservice informations of their own.
>>> Besides, chassis requests also need to provide a compatible interface for
>>> requests to use. There comes to the component RegistryUtils. It is
>>> responsible for the following stuff:
>>>
>>> -
>>>
>>> Initialize service registry client with configurations.
>>> -
>>>
>>> Initialization of service center service, attach with a PullTask.
>>> -
>>>
>>> Initialization of service itself, attach with RegisterTask,
>>> HeartbeatTask and WatchTask.
>>> -
>>>
>>> Provide wrapper method for service registry client.
>>>
>>> The initialization process of service registry client is as follows:
>>>
>>>
>>>
>>>
>>> If the auto discovery switch is on, it need to create a period task
>>> PullTask to make the available service center services' information up
>>> to date.
>>>
>>> Any requests to a new microservice will create a new entry in the
>>> service registry client. Once we access the same microservice again, the
>>> client will response with the cached version which reduces communication
>>> cost with service center.
>>>
>>> Let's checkout how the Microservice component works. Instances and its
>>> versions are cached inside the microservice. To get an instance of a
>>> specified id, all it needs to do is lookup the cache or create a query task
>>> to update the cache. All interactions from Microservice to ApiManager
>>> are done by the Task.
>>>
>>> The ApiManager is designed to interact directly with service center as
>>> a pure client with api inside only. Its structure is as follows:
>>>
>>>
>>> Best Regards!Eric Lee
>>>
>>
>>
>
Re: refactor/rewrite service registry module in Java Chassis
Posted by Willem Jiang <wi...@gmail.com>.
Hi Eric,
You can put this document into the ServiceComb website as a proposal for
refactoring the service center module.
In this way we can keep the other people in the loop of latest updated
design doc.
Willem Jiang
Blog: http://willemjiang.blogspot.com (English)
http://jnn.iteye.com (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On Tue, Dec 19, 2017 at 5:06 PM, Eric Lee <er...@gmail.com> wrote:
> My bad, turns out the images are unable to show in some mailbox. The pdf
> version is in the attachment.
>
> Best Regards!
> Eric Lee
>
> 2017-12-19 16:45 GMT+08:00 Eric Lee <er...@gmail.com>:
>
>> Hi, all
>>
>> We plan to refactor/rewrite the service registry module in Java Chassis. This
>> module is mainly responsible for the interaction between service center and
>> the microservices developed by Java Chassis, namely, client side
>> implementation for service registration and discovery. The analysis of this
>> module and what it supposed to be is mentioned below. Any questions or
>> suggestions are welcomed.
>>
>> Background
>>
>> The architecture of the service registry module in Java Chassis is as
>> follows.
>>
>> However, it has the following problems:
>>
>> -
>>
>> Low level components access high level components frequently. The
>> cyclic relationships make the implementation complicated and introduce some
>> redundant access points.
>> -
>>
>> Low level components should be stateless to be reused by high level
>> components. Introducing state into low level components makes it relies
>> heavily on the high level components, causing cyclic relationships.
>> -
>>
>> Hard to integrate with third-party framework. It does not provide a
>> standalone client with cache capability inside. It also requires the
>> configurations should be loaded from dynamic properties.
>>
>> Proposed Architecture
>>
>>
>>
>>
>> The above architecture is what the service registry module supposed to
>> be in my opinion. The low level components like ApiManager and UriManager
>> are stateless so they do not rely on high level components any more.
>> Relationships between components are clear and simple.
>>
>> Tasks can be divided into the following parts:
>>
>>
>>
>>
>> There are two types of tasks:
>>
>> -
>>
>> Simple Task. Task that executes only once.
>> -
>>
>> Period Task. Task that executes at every interval.
>>
>> The result of task will convert to event and posts to the EventManager.
>> Any methods that subscribes that kind of event will be notified and execute
>> the corresponding response, e.g. update the cache.
>>
>> Both the outside requests and chassis requests share the same interface
>> of Configuration, they can implement their own way to load configurations.
>> The difference between chassis requests and outside requests is that
>> chassis requests need to manage microservice informations of their own.
>> Besides, chassis requests also need to provide a compatible interface for
>> requests to use. There comes to the component RegistryUtils. It is
>> responsible for the following stuff:
>>
>> -
>>
>> Initialize service registry client with configurations.
>> -
>>
>> Initialization of service center service, attach with a PullTask.
>> -
>>
>> Initialization of service itself, attach with RegisterTask,
>> HeartbeatTask and WatchTask.
>> -
>>
>> Provide wrapper method for service registry client.
>>
>> The initialization process of service registry client is as follows:
>>
>>
>>
>>
>> If the auto discovery switch is on, it need to create a period task
>> PullTask to make the available service center services' information up
>> to date.
>>
>> Any requests to a new microservice will create a new entry in the service
>> registry client. Once we access the same microservice again, the client
>> will response with the cached version which reduces communication cost with
>> service center.
>>
>> Let's checkout how the Microservice component works. Instances and its
>> versions are cached inside the microservice. To get an instance of a
>> specified id, all it needs to do is lookup the cache or create a query task
>> to update the cache. All interactions from Microservice to ApiManager
>> are done by the Task.
>>
>> The ApiManager is designed to interact directly with service center as a
>> pure client with api inside only. Its structure is as follows:
>>
>>
>> Best Regards!Eric Lee
>>
>
>
Re: refactor/rewrite service registry module in Java Chassis
Posted by Eric Lee <er...@gmail.com>.
My bad, turns out the images are unable to show in some mailbox. The pdf
version is in the attachment.
Best Regards!
Eric Lee
2017-12-19 16:45 GMT+08:00 Eric Lee <er...@gmail.com>:
> Hi, all
>
> We plan to refactor/rewrite the service registry module in Java Chassis. This
> module is mainly responsible for the interaction between service center and
> the microservices developed by Java Chassis, namely, client side
> implementation for service registration and discovery. The analysis of this
> module and what it supposed to be is mentioned below. Any questions or
> suggestions are welcomed.
>
> Background
>
> The architecture of the service registry module in Java Chassis is as
> follows.
>
> However, it has the following problems:
>
> -
>
> Low level components access high level components frequently. The
> cyclic relationships make the implementation complicated and introduce some
> redundant access points.
> -
>
> Low level components should be stateless to be reused by high level
> components. Introducing state into low level components makes it relies
> heavily on the high level components, causing cyclic relationships.
> -
>
> Hard to integrate with third-party framework. It does not provide a
> standalone client with cache capability inside. It also requires the
> configurations should be loaded from dynamic properties.
>
> Proposed Architecture
>
>
>
>
> The above architecture is what the service registry module supposed to be
> in my opinion. The low level components like ApiManager and UriManager
> are stateless so they do not rely on high level components any more.
> Relationships between components are clear and simple.
>
> Tasks can be divided into the following parts:
>
>
>
>
> There are two types of tasks:
>
> -
>
> Simple Task. Task that executes only once.
> -
>
> Period Task. Task that executes at every interval.
>
> The result of task will convert to event and posts to the EventManager.
> Any methods that subscribes that kind of event will be notified and execute
> the corresponding response, e.g. update the cache.
>
> Both the outside requests and chassis requests share the same interface of
> Configuration, they can implement their own way to load configurations. The
> difference between chassis requests and outside requests is that chassis
> requests need to manage microservice informations of their own. Besides,
> chassis requests also need to provide a compatible interface for requests
> to use. There comes to the component RegistryUtils. It is responsible for
> the following stuff:
>
> -
>
> Initialize service registry client with configurations.
> -
>
> Initialization of service center service, attach with a PullTask.
> -
>
> Initialization of service itself, attach with RegisterTask,
> HeartbeatTask and WatchTask.
> -
>
> Provide wrapper method for service registry client.
>
> The initialization process of service registry client is as follows:
>
>
>
>
> If the auto discovery switch is on, it need to create a period task
> PullTask to make the available service center services' information up to
> date.
>
> Any requests to a new microservice will create a new entry in the service
> registry client. Once we access the same microservice again, the client
> will response with the cached version which reduces communication cost with
> service center.
>
> Let's checkout how the Microservice component works. Instances and its
> versions are cached inside the microservice. To get an instance of a
> specified id, all it needs to do is lookup the cache or create a query task
> to update the cache. All interactions from Microservice to ApiManager are
> done by the Task.
>
> The ApiManager is designed to interact directly with service center as a
> pure client with api inside only. Its structure is as follows:
>
>
> Best Regards!Eric Lee
>