微服務(wù)架構(gòu)這個概念出來也有幾年的時間了，從最開始在互聯(lián)網(wǎng)企業(yè)的廣泛應(yīng)用，到現(xiàn)在越來越多的企業(yè)開始關(guān)注和希望嘗試使用微服務(wù)架構(gòu)。
對于企業(yè)從傳統(tǒng)IT架構(gòu)到微服務(wù)架構(gòu)的轉(zhuǎn)型，絕對不是盲目的跟風(fēng)互聯(lián)網(wǎng)企業(yè)，而是企業(yè)的業(yè)務(wù)規(guī)范，企業(yè)的信息化水平和IT成熟度發(fā)展到一定階段后的比如訴求，那么這些關(guān)鍵的訴求究竟有哪些？
從系統(tǒng)規(guī)劃建設(shè)期到IT管控治理和運維期
首先可以看到當(dāng)企業(yè)的信息化和IT系統(tǒng)建設(shè)發(fā)展到一定階段后，自然會從IT系統(tǒng)的規(guī)劃和建設(shè)期發(fā)展到后期的IT系統(tǒng)管控治理和運維期。到了后期不會再有大量的新系統(tǒng)規(guī)劃建設(shè)，而更多的都是為了業(yè)務(wù)流程優(yōu)化進行的IT系統(tǒng)需求變更，優(yōu)化和功能改造。那么關(guān)鍵的問題就變成了如何快速的響應(yīng)業(yè)務(wù)需求變化并發(fā)布系統(tǒng)，同時如何又以最小的代價和影響來發(fā)布系統(tǒng)？
傳統(tǒng)的IT架構(gòu)模式可以看到很難解決這個問題，每次需求或功能變更的發(fā)布周期相當(dāng)長，同時由于是一個大單體應(yīng)用全部發(fā)布，往往增加了一個新功能反而導(dǎo)致多個老功能出問題。這些都是我們經(jīng)常遇到的問題，其核心的原因就是原來我們管理的業(yè)務(wù)系統(tǒng)本身的顆粒度太大了，其次就是從需求到開發(fā)到測試到發(fā)布整個過程如何自動化銜接。第一點涉及到微服務(wù)架構(gòu)，第二點涉及到PaaS和DevOps方面的內(nèi)容。
在微服務(wù)架構(gòu)下，我們管理的單位從原來的大單體應(yīng)用變化為了細粒度的微服務(wù)模塊，自然在變更和發(fā)布的時候影響單位也相應(yīng)變小到各個業(yè)務(wù)模塊粒度。這將有效的解決子在后期運維變更功能發(fā)布的影響。
從業(yè)務(wù)組織和IT系統(tǒng)緊耦合到解耦需求
其次，在傳統(tǒng)IT系統(tǒng)規(guī)劃和建設(shè)中，在企業(yè)架構(gòu)規(guī)劃設(shè)計中，我們經(jīng)常談業(yè)務(wù)和流程驅(qū)動IT，強調(diào)端到端流程的貫通。但是系統(tǒng)規(guī)劃設(shè)計和實現(xiàn)的過程中，最普遍的現(xiàn)象就是不是業(yè)務(wù)驅(qū)動IT，而是業(yè)務(wù)部門驅(qū)動IT，導(dǎo)致我們的IT系統(tǒng)和業(yè)務(wù)部門是緊耦合的。舉例來說，一個企業(yè)只有供應(yīng)鏈部，那么建設(shè)的系統(tǒng)就是供應(yīng)鏈系統(tǒng)；但是如果一個企業(yè)有采購部，有物流部，那么建設(shè)完成的系統(tǒng)就是采購系統(tǒng)和物流系統(tǒng)。
在這種情況下，帶來的最大問題就是企業(yè)的業(yè)務(wù)組織架構(gòu)一調(diào)整，往往帶來IT系統(tǒng)巨大的調(diào)整工作量，在我原來的企業(yè)也經(jīng)常遇到IT系統(tǒng)經(jīng)常配合業(yè)務(wù)組織架構(gòu)調(diào)整的事情。這類工作已經(jīng)不是簡單的HR系統(tǒng)組織結(jié)構(gòu)調(diào)整，還包括了本身的業(yè)務(wù)系統(tǒng)中業(yè)務(wù)功能點的調(diào)整，已有的業(yè)務(wù)數(shù)據(jù)的調(diào)整，這些都需要進行動態(tài)切換和割接。
當(dāng)企業(yè)建設(shè)的業(yè)務(wù)系統(tǒng)越多，和業(yè)務(wù)部門關(guān)系綁定的越緊密，這種調(diào)整帶來的復(fù)雜度和工作量也就越大。
而真正的解決思路就是要將業(yè)務(wù)部門和業(yè)務(wù)系統(tǒng)解耦，如何解耦？仍然是從業(yè)務(wù)流程驅(qū)動的角度去考慮和拆分具體的業(yè)務(wù)單元，這些業(yè)務(wù)單元形成獨立的業(yè)務(wù)組件（微服務(wù)架構(gòu)中的微服務(wù)模塊），由于這些業(yè)務(wù)組件粒度已經(jīng)足夠細，因此更加容易靈活的組裝或組合去滿足實際業(yè)務(wù)部門的日常業(yè)務(wù)需求。
舉例來說：如果是大的供應(yīng)鏈部門，就配置供應(yīng)商管理，物料管理，采購訂單，招投標，庫存管理，物流配送管理等多個微服務(wù)模塊。如果是拆分為采購部門和物流部門，那么采購部門配置供應(yīng)商管理，物料管理，采購訂單，招投標管理，物流部門配置庫存管理，物流配送管理等微服務(wù)模塊。
在規(guī)劃和拆分微服務(wù)模塊的時候更多是業(yè)務(wù)和流程角度出發(fā)，只要劃分的足夠合理，就能夠最小化的減小業(yè)務(wù)組織架構(gòu)調(diào)整對IT系統(tǒng)本身造成的影響。
從單打獨斗信息孤島到共享思路下的平臺戰(zhàn)略
企業(yè)信息化發(fā)展到一定階段，自己都會意識到按照傳統(tǒng)的一個個孤立的業(yè)務(wù)系統(tǒng)建設(shè)模式越來越行不通，這不僅僅是業(yè)務(wù)系統(tǒng)很多功能重復(fù)建設(shè)的問題，同時還導(dǎo)致了業(yè)務(wù)系統(tǒng)中數(shù)據(jù)不一致性，集成困難，后續(xù)的運維和變更處理困難等一系列問題。即典型的錢花的更多，但是系統(tǒng)卻越來越復(fù)雜和難用。
而解決這個問題的的關(guān)鍵就是平臺戰(zhàn)略，對于平臺戰(zhàn)略本身又有兩個重要的核心，即不是簡單的遺留系統(tǒng)能力直接服務(wù)化共享，而是首先要集中，其次才是共享。集中化是云的思路，而共享才是SOA的思路，兩個關(guān)鍵點都解決了才是云計算+SOA的關(guān)鍵思路融合。
為啥要把這個問題在微服務(wù)架構(gòu)里面談，因為平臺+應(yīng)用構(gòu)建模式本身也是微服務(wù)架構(gòu)實施的一個基礎(chǔ)條件，微服務(wù)模塊更多都應(yīng)該是獨立承擔(dān)某個業(yè)務(wù)域的業(yè)務(wù)組件模塊，而不應(yīng)該包括類似流程引擎，系統(tǒng)管理等共性底層組件，否則微服務(wù)模塊又變成很重的單體應(yīng)用，沒有了任何價值。
要做好微服務(wù)架構(gòu)，我們就必須做好底層基礎(chǔ)共性平臺的建設(shè)，只是微服務(wù)架構(gòu)里面會談為共性的技術(shù)服務(wù)能力提供，都是一個道理，就是共性的東西或能力要下沉，然后再以標準的服務(wù)接口方式暴露或共享出來給上層的業(yè)務(wù)系統(tǒng)使用。
資源池的有效利用和資源動態(tài)調(diào)度
這是微服務(wù)架構(gòu)結(jié)合PaaS容器化技術(shù)和動態(tài)調(diào)度技術(shù)后帶來的一個新的亮點，即可以真正實現(xiàn)按照業(yè)務(wù)需求和業(yè)務(wù)并發(fā)量動態(tài)的申請和分配資源，以滿足業(yè)務(wù)并發(fā)訪問的需求。在整個過程中不需要人為去干預(yù)，而只需要設(shè)置好相應(yīng)的調(diào)度規(guī)則和資源動態(tài)擴展規(guī)則即可。
對于這個點實際當(dāng)前并不是很強企業(yè)的訴求，只是后續(xù)成熟度發(fā)展到一定階段后帶來的亮點功能，真正解決了IT系統(tǒng)的靈活資源分配，擴展和動態(tài)調(diào)度問題。
作者：何明璐
第三十四屆CIO班招生
北達軟EXIN網(wǎng)絡(luò)空間與IT安全基礎(chǔ)認證培訓(xùn)
北達軟EXIN DevOps Professional認證培訓(xùn)
責(zé)編：yangjun
免責(zé)聲明：本網(wǎng)站（http://www.www.gypb.net/）內(nèi)容主要來自原創(chuàng)、合作媒體供稿和第三方投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關(guān)資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責(zé)任。
本網(wǎng)站刊載的所有內(nèi)容（包括但不僅限文字、圖片、LOGO、音頻、視頻、軟件、程序等）版權(quán)歸原作者所有。任何單位或個人認為本網(wǎng)站中的內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，請及時通知本站，予以刪除。
搶沙發(fā)
