I'm now working on some generic architecture-refactoring work, I'd like to
share what I'm doing, your comments and feedbacks are very welcome
Currently there are two major types of components that have
inter-component interaction beyond Java method-call-bindings, one is
Resource and the other one is what we called managers. Resources usually
residents within their tenant environment(agent at client side or
management server itself at server side), and managers run directly inside
management server. Resources and managers communicate each other by
exchanging Commands and Answers.
For rest of other modules (for example, so called
plugins/Gurus/Elements/Adapters), they usually bind to corresponding
managers through normal Java method-calls.
>From high level perspective, the architecture looks relatively clean,
however, as we add more and more features, things start to become murky,
the major issue of this architectures is that we are lack of a clear
middle layer for various components to build up interactions, so we end up
with things like, a network component might need to wire agent manager in
order to communicate with a particular agent. And agent manager itself, in
addition to provide a communication layer, it has baked in a lot of
CloudStack business logic to define what a agent should behave like (i.e.,
StartupCommand/RoutingStartupCommand, etc).
I'll start to work on following things to make CloudStack reshape into
multi-layered architecture, focusing on providing a uniformed grand for
components to interactive with each other and give all components
first-class citizenship within CloudStack system
1) a low-level messaging layer
This layer provides three major functions
- endpoint address space that across management servers (clustering will
be embedded solely within this layer and be transparent to high level
components)
- generic message delivery, Yes, just plain arbitrary message delivery
- protocol multiplexing, allow applications on top of
2) Event bus for component signaling
A multiplexed layer on top of messaging layer, it provides
publisher/subscriber pattern within management server node, cross
management server nodes to provide light-weight signaling mechanism
between components
3) RPC/Async RPC layer
- A multiplexed layer on top of messaging layer, although components are
free to use any other RPC mechanism, however, within CloudStack internal,
this generic RPC/Async RPC facility may probably be used the most.
- sequence control
4) Event dispatching mechanism for Async orchestration
Kelven
