Shulou(Shulou.com)05/31 Report--

Today, I will talk to you about the general plug-in system ZStack, which may not be well understood by many people. in order to make you understand better, the editor has summarized the following content for you. I hope you can get something according to this article.

Current IaaS software is more like cloud controller software, and it lacks many features (features) to become a complete cloud solution. As a developing technology, it is very difficult to predict all the necessary features of a complete solution, so it is impossible for an IaaS software to complete all its features in the first place. Based on the above facts, the architecture of an IaaS software must have the ability to keep the core structure stable while adding new features. ZStack's universal plug-in system enables features to be implemented like plug-ins (in-thread or out-of-thread), which not only extends the functionality of ZStack, but also can be injected into business logic to change the default behavior.

motivation

In the current situation of IaaS software, with the exception of some very well-built IaaS (like AWS), most IaaS (including our ZStack) is still not a complete cloud solution. Thanks to pioneers like Amazon who have been exploring for years, the public cloud already has a more mature model for what a public cloud solution should look like. Because it is still in the development stage, the private cloud does not have a complete and validated solution yet. Unlike dedicated public cloud software, which can be tailored to the manufacturer's infrastructure and services, open source IaaS software must take into account the needs of both public and private clouds, making it more difficult to create a complete solution. Because we have no way to predict what a complete solution should look like, our only way is to provide a plug-in architecture that can add plug-ins without affecting the stability of the core business.

problem

A lot of software claims to be plug-in, but many are not really plug-in, or at least not completely plug-in. Before explaining why, let's look at the two main forms of plug-in architecture. Although this topic has been discussed in many articles, in our experience, we have summarized all plug-ins into two structures, which can be accurately described as the strategy pattern and observer pattern in GoF design patterns.

Plug-ins derived from strategist mode

This form of plug-in usually extends software-specific functionality by providing different implementations, or adds new functionality by adding plug-in APIs. Many of the software we are familiar with are built through this mode, such as operating system drivers and web browser plug-ins. This plug-in works by allowing the application to access the plug-in through a well-defined protocol.

Plug-ins derived from observer mode

This form of plug-in is usually injected into the application's business logic for specific events. Once an event occurs, the plug-in hanging above is called to execute a piece of code that may even change the execution flow, for example, when the event meets certain conditions, an exception is thrown to stop the execution flow. Plug-ins based on this pattern are usually transparent and purely internal to the end user, for example, a listener listens for database insert events. This plug-in works by allowing the plug-in to access the application through well-defined extension points.

Most software claims that they are plug-in, either implementing one of these components or having a part of the code that implements them. In order to become fully plug-in, the software must envision the idea that all business logic is implemented in both ways. This means that the whole software is made up of a large number of small plug-ins, just like Lego toys.

Plug-in system

An important design principle runs through all ZStack components: every component should be designed in this way, least informative, self-contained, and independent of other components. For example, in order to create a virtual machine, allocating disks, providing DHCP, and establishing a SNAT are all necessary steps, and managing the components that create the VM should be very clear. But does it really need to know so much? Why can't this component be reduced to allocating VM's CPU/ memory and then sending startup requests to the host, allowing other components, such as storage and networking, to take care of their own business? You may have guessed the answer: no, in ZStack, components don't need to know that much, that's right! It can be that simple. We are fully aware of the fact that the more information your components know, the more closely your application is coupled, and you end up with complex software that is difficult to modify. So we provide the following plug-in forms to ensure that our architecture is loosely coupled and make it easy for us to add new features to form a complete cloud solution.

1. Policy mode plug-in

Usually plug-ins in IaaS software are drivers that integrate different physical resources. For example, NFS primary storage, ISCSI primary storage, VLAN-based L2 network, Open vSwitch-based L2 network; these plug-ins are all in the form of the policy pattern we just mentioned. ZStack has abstracted cloud resources into: virtual machine manager, primary storage, backup storage, L2 network, L3 network, and so on. Each resource has an associated driver as a separate plug-in. To add a new driver, the developer only needs to implement three components: a type, a factory, and a specific resource implementation, all encapsulated in a single plug-in, usually built into a jar file. Citing Open vSwitch as an example, let's assume that we will create a new L2 network using Open vSwitch as the background, and then the developer needs:

Define an Open vSwitch type L2 network that will automatically register with the ZStack L2 network type system. Public static L2NetworkType type = new L2NetworkType ("Openvswitch"); / * once the type is declared as above, there will be a new L2 network type called 'Openvswitch' that can be retrieved by API * / (once the type is declared, a new L2 network type called "Openvswitch" can be retrieved by API) 1.2 create an L2 network factory responsible for returning a specific implementation to the L2 network service. Public class OpenvswitchL2NetworkFactory implements L2NetworkFactory {[@ Override] (https://my.oschina.net/u/1162528) public L2NetworkType getType () {/ * return type defined in 1.1 * / return type } [@ Override] (https://my.oschina.net/u/1162528) public L2NetworkInventory createL2Network (L2NetworkVO vo, APICreateL2NetworkMsg msg) {/ * new resource will normally have own creational API APICreateOpenvswitchL2NetworkMsg that * usually inherits APICreateL2NetworkMsg, and own database object OpenvswitchL2NetworkVO that * usually inherits L2NetworkVO, and a java bean OpenvswitchL2NetworkInventory that usually inherits * L2NetworkInventory representing all properties of OpenvswitchL2 network. * / (the new resource will usually have a created API APICreateOpenvswitchL2NetworkMsg, usually inherited from APICreateL2NetworkMsg, and will also have its own database object, OpenvswitchL2NetworkVO, which usually inherits from L2NetworkVO, and a java bean OpenvswitchL2NetworkInventory, which usually represents all the attributes of the OpenvswitchL2 network in L2NetworkInventory) APICreateOpenvswitchL2NetworkMsg cmsg = (APICreateOpenvswitchL2NetworkMsg) APICreateL2NetworkMsg; OpenvswitchL2NetworkVO cvo = new OpenvswitchL2NetworkVO (vo); evaluate_OpenvswitchL2NetworkVO_with_parameters_in_API (cvo, cmsg); save_to_database (cvo) Return OpenvswitchL2NetworkInventory.valueOf (cvo);} [@ Override] (https://my.oschina.net/u/1162528) public L2Network getL2Network (L2NetworkVO vo) {/ * return the concrete implementation defined in 1.3 * / return new OpenvswitchL2Network (vo);}} 1.3 create a specific Open vSwitch L2 network implementation to interact with the background Open vSwitch controller. Public class OpenvswitchL2Network extends L2NoVlanNetwork {public OpenvswitchL2Network (L2NetworkVO self) {super (self);} [@ Override] (https://my.oschina.net/u/1162528) public void handleMessage (Message msg) {/ * handle OpenvswitchL2 network specific messages (both API and non API) and delegate * others to the base class L2NoVlanNetwork; so the implementation can focus on own business * logic and let the base class handle things like attaching cluster, detaching cluster * of course, the implementation can override any message handler if it wants, for example, * override L2NetworkDeletionMsg to do some cleanup work before being deleted. (handle specific messages related to the Openvswitch L2 network (API messages or messages that are not API messages) and hand other messages to the basic class of L2NoVlanNetwork for processing So its implementation can focus on its own business logic and let the basic class handle things such as binding and unbinding clusters. Of course, the implementation can also override any message processor, for example, overriding L2NetworkDeletionMsg to do some cleaning before deletion. ) * / if (msg instanceof OpenvswitchL2NetworkSpecificMsg1) {handle ((OpenvswitchL2NetworkSpecificMsg1) msg);} else if (msg instanceof OpenvswitchL2NetworkSpecificMsg2) {handle ((OpenvswitchL2NetworkSpecificMsg2) msg);} else {super.handleMessage (msg);}

Put the three components together in a Maven module, add some necessary Spring configuration files, compile them into JAR files, and you create a new L2 network type in ZStack. All Zstack resource drivers are implemented through the above steps (type, factory, concrete implementation). Once you have learned how to create a driver for a resource, you have learned how to do so for all resources. As we mentioned in "Micro Services Architecture in the ZStack-- process", drivers can have their own API and configuration methods.

two。 Observer mode plug-in

The plug-in (driver) of the strategy pattern allows you to extend the functionality of the existing ZStack; however, in order to make the architecture loosely coupled, the plug-in must be able to inject the business logic of the application, or even the business logic of other plug-ins; the key to observing the pattern plug-in is the extension point, which allows a piece of plug-in code to be invoked while a code flow is running. Zstack currently defines about 100 extension points, exposing a large number of scenarios in which plug-ins receive events or change code flow behavior. To create a new extension point is to define a java interface, and components can easily create extension points to allow other components to inject their own business logic. To see how it works, let's continue with our Open vSwitch example; suppose the Open vSwitch L2 network needs to hook into the process of creating a VM to prepare the GRE tunnel before the VM is created, which is implemented as follows:

PreVmInstantiateResourceExtensionPoint:public class OpenvswitchL2NetworkCreateGRETunnel implements PreVmInstantiateResourceExtensionPoint {[@ Override] (https://my.oschina.net/u/1162528) public void preBeforeInstantiateVmResource (VmInstanceSpec spec) throws VmInstantiateResourceException {/ * * you can do some check here If any condition makes you think the VM should not be created/started, * you can throw VmInstantiateResourceException to stop it * /} @ Override public void preInstantiateVmResource (VmInstanceSpec spec, Completion completion) {/ * create the GRE tunnel, you can get all necessary information about the VM from VmInstanceSpec * / completion.success () } @ Override public void preReleaseVmResource (VmInstanceSpec spec, Completion completion) {/ * * in case VM fails to create/start for some reason, for cleanup, you can delete the prior created GRE tunnel here * / completion.success ();}}

When ZStack connects to the KVM host and the Open vSwitch L2 network wants to check and start the Open vSwitch daemon on the host, it implements KVMHostConnectExtensionPoint:

Public class OpenvswitchL2NetworkKVMHostConnectedExtension implements KVMHostConnectExtensionPoint {@ Override public void kvmHostConnected (KVMHostConnectedContext context) throws KVMHostConnectException {/ * * you can use various methods like SSH login, HTTP call to KVM agent to check the Openvswitch daemon you can use many ways (such as SSH login, HTTP call of KVM agent) to check the daemon of Openvswitch on the host by using the information on KVMHostConnectedContext. If any state makes you think that the host cannot provide an Openvswitch L2 network method, you can throw a KVMHostConnectExtensionPoint to prevent the host from connecting. * on the host, using information in KVMHostConnectedContext. If any condition makes you think the * host cannot provide Openvswitch L2 network function, you can throw KVMHostConnectExtensionPoint to * stop the host from being connected. * /}}

Finally, you need to advertise that you have two components that implement these extension points, and ZStack's plug-in system will ensure that the owner invokes your component at an appropriate time. The notification is done in the plug-in's Spring configuration file:

That's all you need to do. Create a new type of L2 network without even changing a single line of code for any other ZStack component. This is the basis for ZStack to keep its core business processes stable.

Don't OSGI: people familiar with Eclipse and OSGI may have noticed that our plug-in system is very similar to eclipse and OSGI. One might ask why we don't use OSGI directly, which is specifically designed to create plug-in systems for Java applications. In fact, we spent a lot of time trying OSGI;, however, we felt that it was pushing too hard. We don't like having another container in our application, we don't like a separate class loader, and we don't like the complexity of creating plug-ins. It looks like OSGI is putting a lot of effort into isolating plug-ins from each other, but ZStack wants plug-ins to be flattened. We have noticed that many projects have introduced unnecessary restrictions in their code so that the overall architecture is clearly hierarchical and isolated, but because of poorly designed interfaces, plug-ins have to write a lot of ugly code to overcome these limitations. instead, it disrupts the real architecture. ZStack considers all plug-ins as part of its core and has the same privileges for core business processes. We are not building a consumer application similar to a browser, and users may mistakenly install malicious plug-ins; we are building enterprise software that needs to be rigorously tested in every corner. A flat plug-in system makes our code simple and robust.

3. Out-of-process services (plug-ins)

In addition to the above two ways, developers do have a third way to extend ZStack-- out-of-process services. Although ZStack packages all orchestration services as a single process, functions independent of business process services can be implemented as independent services, which run on different processes or even different machines. ZStack Web UI, a Python application that interacts with ZStack orchestration services through RabbitMQ, is a good example. ZStack has a well-defined messaging specification, and out-of-process services can be written in any language, as long as they can interact through RabbitMQ. ZStack also has a mechanism called canonical event that exposes internal events to the bus, such as VM creation, VM stop, and disk creation. Software such as a billing system can build an out-of-process service by listening for these events. If a service wants to be out of process, but still needs to access the data structures of some core business processes that have not yet been exposed, or needs to access databases, it can use a hybrid approach, that is, a small plug-in on the management node is responsible for collecting data and sending it to the message agent, and services outside the process accept the data and do their own things.

After reading the above, do you have any further understanding of the general plug-in system ZStack? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.