摘要：但在实际的二次开发中，这些做法未必能够完全满足需求。在源码剖析之核心库鉴赏一文中，我们了解到是的基础设施之一，同时也允许通过显示声明的方式来声明。同理，一些也可以使用继承进行扩展。
本文首发于泊浮目的专栏：https://segmentfault.com/blog...前言
在ZStack博文-5.通用插件系统中，官方提出了几个较为经典的扩展方式。但在实际的二次开发中，这些做法未必能够完全满足需求。今天笔者就和大家一起来看一看一些常见的扩展方法。
扩展是最佳选项ZStack作为一个开源的产品化Iaas，随着其每个版本的更新发布，都携带了极多的feature，并由其测试天团进行严密的测试后发布来保证质量。同时，每个版本也会携带大量的bug fix。
如果在自己fork的ZStack中耦合了过多自己的代码（对于Iaas的扩展或自己的业务逻辑），会导致跟不上master分支，这样会丢失掉很多高质量feature和bug的fix。
扩展的特殊技巧 ExtensionPoint在ZStack源码剖析之设计模式鉴赏——三驾马车中，笔者提到过基于观察者模式的ExtensionPoint。其本质是通过Java的Interface来定义一系列的实现类，并收集它们来调用，这样它们可以散落在各个模块中，但在Application起来时它们却一起被Spring加载到了内存中。
利用这种方法，我们可以很容易的添加自己的代码到模块中，但又不影响主干代码。
在此前提上，也可以关注代码中的ExtensionPointEmitter，该组件也是参考了这样的设计。
Flow在ZStack源码剖析之核心库鉴赏——FlowChain一文中，我们了解到Flow是ZStack的基础设施之一，同时也允许通过XML显示声明的方式来声明Flow。因此，我们可以通过添加自己的Flow来执行一些自己的扩展逻辑。
Event基于EventFacadefire的路径上定义接收点。如在HostBase中，定义了HOST_DELETED_PATH。我们可以选择在自己的代码模块中注册一个evft.on。用于执行自己的逻辑。
chain.done(new FlowDoneHandler(msg) {
@Override
public void handle(Map data) {
casf.asyncCascadeFull(CascadeConstant.DELETION_CLEANUP_CODE, issuer, ctx, new NopeCompletion());
bus.publish(evt);
HostDeletedData d = new HostDeletedData();
d.setInventory(HostInventory.valueOf(self));
d.setHostUuid(self.getUuid());
evtf.fire(HostCanonicalEvents.HOST_DELETED_PATH, d);
}
}).error(new FlowErrorHandler(msg) {
@Override
public void handle(ErrorCode errCode, Map data) {
evt.setError(errf.instantiateErrorCode(SysErrors.DELETE_RESOURCE_ERROR, errCode));
bus.publish(evt);
}
}).start();
Backend
这里以KvmBackend为例，我们先简单的看一下这个类
public class KvmBackend extends HypervisorBackend
而HypervisorBackend继承了HypervisorBackend，HypervisorBackend继承了SMPPrimaryStorageBase，SMPPrimaryStorageBase继承了PrimaryStorageBase。
我们来看一下，KvmBackend 里handle什么样的消息。
我们可以看到，这些Msg执行的逻辑和主存储类型息息相关，不能以同一个PrimaryStorageBase来一概而论。因此，同一个Msg在不同类型的存储、不同的场景下会有不一样的逻辑来handle。
同理，一些ManagerImpl也可以使用继承进行扩展。
简单来说，就是对基类进行扩展，覆写那些我们需要修改的方法。
模块化工程在ZStack中，有许许多多的代码模块。在扩展自己的业务逻辑时，最好新建一个Module用于存放自己的代码，对于模块和Bean的依赖可以按需放入（类似Plugin的形式）。并结合以上的几个方式来进行扩展。
那么在这个过程中，该注意哪些事项呢？
Spring的配置在ZStack中，我们可以看到所有的Bean配置都是由ZStack.xml管理的，
而引用xml的地方则是这里：
因此，我们需要注意引入的xml是否有被配置起来。
ZStack使用了Hibernate 这个ORM框架，并对映射类用XML的形式来管理。即：persistence.xml。
需要注意的是，在DatabaseFacade的XML配置文件中，引用了该配置文件。因此对于这个文件的方式建议是覆写（即再创建一个persistence.xml，用于引用ZStack中的表对象和自己的表对象），而不是再配置一个进行引用。因为这样可能会影响主干代码。
ZStack在Test目录下提供了大量Case。在完成自己的扩展后（照理论上来说不应该改动ZStack的源代码），可以尝试在该目录下跑所有的Case：
mvn compile && cd test && mvn test -Dtest=ZStackTest
如果都跑过了，则证明ZStack的主干代码可能没有受到影响。
小结在本文中，笔者介绍了几种较为优雅的扩展方式。利用这些方法可以让我们较为方便的跟上主线，避免花大量精力在解决冲突上。
当然，如果大家有更好的扩展方式，也可以在评论区补充。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/69086.html
摘要：本文首发于泊浮目的专栏背景在上篇文章中源码剖析之二次开发可扩展框架，我们简单的了解了一下核心引擎的二次开发技巧。而在没有足够人力来维护开发时，我们会将目标定为能够及时跟上发布版本。 本文首发于泊浮目的专栏：https://segmentfault.com/blog... 背景 在上篇文章中（ZStack源码剖析之二次开发——可扩展框架），我们简单的了解了一下ZStack核心引擎的二次...
摘要：本文首发于泊浮目的专栏在前文源码剖析之二次开发可扩展框架中，我们大概的了解了如何在中进行二次开发。在还有相关的日志，有兴趣的读者可以自行搜索。挂断点在挂断点之前，请确定自己的开放了相应的端口。之后记得使用关掉。 本文首发于泊浮目的专栏：https://segmentfault.com/blog... 在前文 ZStack源码剖析之二次开发——可扩展框架中，我们大概的了解了如何在ZSt...
摘要：本文将对核心引擎的源码进行剖析。在笔者看来，能够快速迭代的原因首先是来自于每位工程师的辛勤付出。在中，还有一类很有意思的代码，一般称之为。笔者有机会将会在之后的系列文章分析其中的典型案例以及在代码中使用极其频繁的核心工具。 本文首发于泊浮目的专栏：https://segmentfault.com/blog... 前言 ZStack是下一代开源的云计算IaaS（基础架构即服务）软件。它...
摘要：本文将对核心引擎的源码进行剖析。在笔者看来，能够快速迭代的原因首先是来自于每位工程师的辛勤付出。在中，还有一类很有意思的代码，一般称之为。笔者有机会将会在之后的系列文章分析其中的典型案例以及在代码中使用极其频繁的核心工具。 本文首发于泊浮目的专栏：https://segmentfault.com/blog... 前言 ZStack是下一代开源的云计算IaaS（基础架构即服务）软件。它...
摘要：本文将对核心引擎的源码进行剖析。在笔者看来，能够快速迭代的原因首先是来自于每位工程师的辛勤付出。在中，还有一类很有意思的代码，一般称之为。笔者有机会将会在之后的系列文章分析其中的典型案例以及在代码中使用极其频繁的核心工具。 本文首发于泊浮目的专栏：https://segmentfault.com/blog... 前言 ZStack是下一代开源的云计算IaaS（基础架构即服务）软件。它...
阅读 1310·2021-11-11 16:54
阅读 2364·2021-09-22 10:51
阅读 2635·2019-08-30 15:44
阅读 3192·2019-08-29 17:05
阅读 1419·2019-08-29 17:01
阅读 2834·2019-08-29 12:28
阅读 2452·2019-08-26 13:50
阅读 1706·2019-08-23 16:47
