摘要:但在實際的二次開發(fā)中,這些做法未必能夠完全滿足需求。在源碼剖析之核心庫鑒賞一文中,我們了解到是的基礎(chǔ)設(shè)施之一,同時也允許通過顯示聲明的方式來聲明。同理,一些也可以使用繼承進行擴展。
本文首發(fā)于泊浮目的專欄:https://segmentfault.com/blog...前言
在ZStack博文-5.通用插件系統(tǒng)中,官方提出了幾個較為經(jīng)典的擴展方式。但在實際的二次開發(fā)中,這些做法未必能夠完全滿足需求。今天筆者就和大家一起來看一看一些常見的擴展方法。
擴展是最佳選項ZStack作為一個開源的產(chǎn)品化Iaas,隨著其每個版本的更新發(fā)布,都攜帶了極多的feature,并由其測試天團進行嚴密的測試后發(fā)布來保證質(zhì)量。同時,每個版本也會攜帶大量的bug fix。
如果在自己fork的ZStack中耦合了過多自己的代碼(對于Iaas的擴展或自己的業(yè)務(wù)邏輯),會導(dǎo)致跟不上master分支,這樣會丟失掉很多高質(zhì)量feature和bug的fix。
擴展的特殊技巧 ExtensionPoint在ZStack源碼剖析之設(shè)計模式鑒賞——三駕馬車中,筆者提到過基于觀察者模式的ExtensionPoint。其本質(zhì)是通過Java的Interface來定義一系列的實現(xiàn)類,并收集它們來調(diào)用,這樣它們可以散落在各個模塊中,但在Application起來時它們卻一起被Spring加載到了內(nèi)存中。
利用這種方法,我們可以很容易的添加自己的代碼到模塊中,但又不影響主干代碼。
在此前提上,也可以關(guān)注代碼中的ExtensionPointEmitter,該組件也是參考了這樣的設(shè)計。
Flow在ZStack源碼剖析之核心庫鑒賞——FlowChain一文中,我們了解到Flow是ZStack的基礎(chǔ)設(shè)施之一,同時也允許通過XML顯示聲明的方式來聲明Flow。因此,我們可以通過添加自己的Flow來執(zhí)行一些自己的擴展邏輯。
Event基于EventFacadefire的路徑上定義接收點。如在HostBase中,定義了HOST_DELETED_PATH。我們可以選擇在自己的代碼模塊中注冊一個evft.on。用于執(zhí)行自己的邏輯。
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執(zhí)行的邏輯和主存儲類型息息相關(guān),不能以同一個PrimaryStorageBase來一概而論。因此,同一個Msg在不同類型的存儲、不同的場景下會有不一樣的邏輯來handle。
同理,一些ManagerImpl也可以使用繼承進行擴展。
簡單來說,就是對基類進行擴展,覆寫那些我們需要修改的方法。
模塊化工程在ZStack中,有許許多多的代碼模塊。在擴展自己的業(yè)務(wù)邏輯時,最好新建一個Module用于存放自己的代碼,對于模塊和Bean的依賴可以按需放入(類似Plugin的形式)。并結(jié)合以上的幾個方式來進行擴展。
那么在這個過程中,該注意哪些事項呢?
Spring的配置在ZStack中,我們可以看到所有的Bean配置都是由ZStack.xml管理的,
而引用xml的地方則是這里:
因此,我們需要注意引入的xml是否有被配置起來。
ZStack使用了Hibernate 這個ORM框架,并對映射類用XML的形式來管理。即:persistence.xml。
需要注意的是,在DatabaseFacade的XML配置文件中,引用了該配置文件。因此對于這個文件的方式建議是覆寫(即再創(chuàng)建一個persistence.xml,用于引用ZStack中的表對象和自己的表對象),而不是再配置一個進行引用。因為這樣可能會影響主干代碼。
ZStack在Test目錄下提供了大量Case。在完成自己的擴展后(照理論上來說不應(yīng)該改動ZStack的源代碼),可以嘗試在該目錄下跑所有的Case:
mvn compile && cd test && mvn test -Dtest=ZStackTest
如果都跑過了,則證明ZStack的主干代碼可能沒有受到影響。
小結(jié)在本文中,筆者介紹了幾種較為優(yōu)雅的擴展方式。利用這些方法可以讓我們較為方便的跟上主線,避免花大量精力在解決沖突上。
當(dāng)然,如果大家有更好的擴展方式,也可以在評論區(qū)補充。
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://specialneedsforspecialkids.com/yun/69086.html
摘要:本文首發(fā)于泊浮目的專欄背景在上篇文章中源碼剖析之二次開發(fā)可擴展框架,我們簡單的了解了一下核心引擎的二次開發(fā)技巧。而在沒有足夠人力來維護開發(fā)時,我們會將目標定為能夠及時跟上發(fā)布版本。 本文首發(fā)于泊浮目的專欄:https://segmentfault.com/blog... 背景 在上篇文章中(ZStack源碼剖析之二次開發(fā)——可擴展框架),我們簡單的了解了一下ZStack核心引擎的二次...
摘要:本文首發(fā)于泊浮目的專欄在前文源碼剖析之二次開發(fā)可擴展框架中,我們大概的了解了如何在中進行二次開發(fā)。在還有相關(guān)的日志,有興趣的讀者可以自行搜索。掛斷點在掛斷點之前,請確定自己的開放了相應(yīng)的端口。之后記得使用關(guān)掉。 本文首發(fā)于泊浮目的專欄:https://segmentfault.com/blog... 在前文 ZStack源碼剖析之二次開發(fā)——可擴展框架中,我們大概的了解了如何在ZSt...
摘要:本文將對核心引擎的源碼進行剖析。在筆者看來,能夠快速迭代的原因首先是來自于每位工程師的辛勤付出。在中,還有一類很有意思的代碼,一般稱之為。筆者有機會將會在之后的系列文章分析其中的典型案例以及在代碼中使用極其頻繁的核心工具。 本文首發(fā)于泊浮目的專欄:https://segmentfault.com/blog... 前言 ZStack是下一代開源的云計算IaaS(基礎(chǔ)架構(gòu)即服務(wù))軟件。它...
摘要:本文將對核心引擎的源碼進行剖析。在筆者看來,能夠快速迭代的原因首先是來自于每位工程師的辛勤付出。在中,還有一類很有意思的代碼,一般稱之為。筆者有機會將會在之后的系列文章分析其中的典型案例以及在代碼中使用極其頻繁的核心工具。 本文首發(fā)于泊浮目的專欄:https://segmentfault.com/blog... 前言 ZStack是下一代開源的云計算IaaS(基礎(chǔ)架構(gòu)即服務(wù))軟件。它...
摘要:本文將對核心引擎的源碼進行剖析。在筆者看來,能夠快速迭代的原因首先是來自于每位工程師的辛勤付出。在中,還有一類很有意思的代碼,一般稱之為。筆者有機會將會在之后的系列文章分析其中的典型案例以及在代碼中使用極其頻繁的核心工具。 本文首發(fā)于泊浮目的專欄:https://segmentfault.com/blog... 前言 ZStack是下一代開源的云計算IaaS(基礎(chǔ)架構(gòu)即服務(wù))軟件。它...
閱讀 1339·2021-11-11 16:54
閱讀 2385·2021-09-22 10:51
閱讀 2655·2019-08-30 15:44
閱讀 3206·2019-08-29 17:05
閱讀 1445·2019-08-29 17:01
閱讀 2900·2019-08-29 12:28
閱讀 2471·2019-08-26 13:50
閱讀 1731·2019-08-23 16:47