雲原生架構與微服務體系

前言:大資料、人工智慧、移動互聯、雲計算、物聯網等新一代資訊科技的發展為企業數字化轉型提供了技術支撐。數字化轉型並不是對企業以往的資訊化推倒重來,而是需要整合最佳化以往的企業資訊化系統,在整合最佳化的基礎上,提升管理和運營水平,運用新的技術手段提升企業新的技術能力,以支撐企業適應數字化轉型變化帶來的新要求。因此,本公眾號將相繼推出企業數字化轉型的關鍵技術與問題一系列推文,以期為目標企業數字化轉型提供借鑑性思路。

“企業數字化轉型的關鍵技術與問題”系列推文四:

雲原生架構與微服務體系

隨著雲計算平臺的成熟和分散式框架的普及,應用上雲已經是不可逆轉的趨勢,未來應用會分成兩種,一種是“構建雲”的,另一種是“基於雲構建”的應用。

真正的雲化不僅僅是基礎設施和平臺的變化,應用也需要做出改變,擯棄傳統的土方法,在架構設計、開發方式、部署維護等各個階段和方面都基於雲的特點重新設計,從而建設全新的雲化的應用,即雲原生應用。

在雲環境下怎樣保證在應用程式越來越大、功能越來越複雜的情況下,還能夠做到敏捷開發並保證可用性呢?雲原生有一套完整的體系和方法論。

雲原生架構與微服務體系

1、

什麼是雲原生?

雲原生是一種構建和執行應用程式的方法,是一套技術體系和方法論。雲原生(CloudNative)是一個組合詞,Cloud+Native。

Cloud表示應用程式位於雲中,而不是傳統的資料中心;

Native表示應用程式從設計之初即考慮到雲的環境,原生為雲而設計,在雲上以最佳姿勢執行,充分利用和發揮雲平臺的彈性+分散式優勢。

不同的人和組織對雲原生有不同的定義,相同的人和組織在不同時間點對雲原生也有不同的定義:

•2013年,Pivotal公司的Matt Stine首次提出雲原生(CloudNative)的概念;

•2015年,Matt Stine在《遷移到雲原生架構》一書中定義了符合雲原生架構的幾個特徵:12因素、微服務、自敏捷架構、基於API協作、扛脆弱性;

•2017年,Pivotal最新官網對雲原生概括為4個要點:DevOps+持續交付+微服務+容器;

•2018年,CNCF又更新了雲原生的定義,把服務網格(Service Mesh)和宣告式API給加了進來;

可以簡單的理解為:

雲原生 = DevOps+持續交付(Continuous Delivery)+微服務(Micro Services)+敏捷基礎設施(Agile Infrastructure)+12要素(The Twelve-Factor App)+服務網格(Service Mesh)+宣告式API。

雲原生不但包括根據業務能力對公司進行文化、組織架構的重組與建設,也包括方法論與原則,還有具體的操作工具。採用基於雲原生的技術和管理方法,可以更好地把業務生於“雲”或遷移到雲平臺,從而享受“雲”的高效和持續的服務能力。

雲原生架構與微服務體系

表1雲原生範疇

雲原生與傳統應用有比較明顯的區別,雲原生更倡導敏捷、自動化、容錯,而傳統應用則大多還處於原生的瀑布開發模型和人工運維階段。

雲原生架構與微服務體系

表2雲原生應用和傳統應用的區別

2、

什麼是微服務?

隨著業務越來越複雜,業務架構也經歷了不斷變化和演進,每一次演進都是為了解決上一代系統架構的痛點。

第一代單體架構

把所有業務依賴的元件、庫全部打包到一個執行程式,業務相互呼叫,大大增加了系統複雜度,導致系統維護成本高,改動影響大,釋出風險高;並且系統完全封閉,內部元件不能共享給其他元件呼叫,導致產品能力不能共享,大大降低開發效率。

第二代面向服務架構

SOA(Service Oriented Architecture)是一種設計方法,其中包含多個服務, 服務之間透過相互依賴最終提供一系列的功能。一個服務通常以獨立的形式存在與作業系統程序中,各個服務之間透過網路呼叫。

第三代微服務架構

是在 SOA 上做的昇華,微服務架構強調的一個重點是“業務需要徹底的元件化和服務化”,原有的單個業務系統會拆分為多個可以獨立開發、設計、執行的小應用。這些小應用之間透過服務完成互動和整合。

微服務是一種去中心化的架構,一般和更細粒度的容器配合使用,天生自帶很強的共生性。從早期的集中式架構,到分散式架構,再到現在更細粒度化的微服務,其實一直朝著去中心化的趨勢發展,具備更強的靈活性以及更適合雲的特點。微服務是未來一種非常主要的、應用廣泛的架構,但並不一定說它會統治一切。微服務化更適合無狀態、高迭代的業務場景。

微服務的粒度與團隊組織方式是相關,與業務功能的構成相關,與資料相關。在業務功能方面,儘量做到一個模組中的業務高度類聚集,和外部模組做到松耦合,獲取靈活性;在資料方面,一個微服務儘量不要和外部頻繁的互動資料,大量的API互動對效能和可靠性都有影響。

雲原生架構與微服務體系

三、微服務在實踐過程中最大的難點是什麼?

微服務在實踐過程中,最大的問題是團隊之間的運作和管理。康威定律提到,有什麼樣的團隊組織方式,就有什麼樣的業務架構。業務架構,是和團隊組織架構相匹配的,當我們把一個大的系統,拆分成小的服務時,團隊會隨之變化。團隊成員需要適應微服務的開發模式,微服務對每個程式設計師有著更高的要求。

微服務實踐的難點不在於沒法拆分,難點在於很多人的思想停留在以前的架構思想下。建議逐步改造、持續迭代地改造架構。新業務、新團隊可以獨立地採用微服務化運作。

四、微服務、容器技術兩者的關係?兩者結合帶來什麼新趨勢?

微服務是一種架構思想,而容器,或者說以Docker為代表的容器技術,是一種執行載體。容器天生適合細粒度的微服務,容器管理和分發需要Docker的支援。兩者結合,就是去中心化思想的實踐。

伴隨網際網路與雲計算的發展,什麼樣的架構或者產品研發模式是適合雲模式的?是傳統的集中式架構嗎?分散式架構嗎?現在創業型公司的特點:完全基於雲端,輕資產,小團隊作戰,快速的產品迭代。為了適應這些特點,必須基於雲的原生特點去設計應用架構,所以微服務和容器發展的新趨勢,就是去實踐Cloud Native。

在雲時代,全部應用都基於雲去構建,並不適合套用傳統的研發模式。Cloud Native是指雲原生的應用架構,是專門針對雲的架構。它主要包括三個部分,一種全新的架構思想(微服務),一種業務執行管理模式,以及一種團隊組織管理方式。關乎DevOps、小團隊、敏捷開發。Cloud Native既不是一個新的技術,也不是一套新的架構,而是產品研發、運營的全新模式。它是在雲的生態場景生長出來的,和雲的關係是一種魚和水的關係。

五、怎麼處理微服務與外部相連,以及獲取資料?

微服務是透過API對外提供服務,本身是一個獨立的自治系統,所以不存在需要與很多資料中心相互連線的情況;如果需要通訊,直接適用公網連線就可以。

換句話說,微服務和微服務之間的資料通訊是透過API呼叫的。沒有所謂的內部的程序間、共享訊號、共享記憶體佇列的模式。一個微服務對外提供的服務一定是封裝好的、介面式的。

總結

雲原生是一種構建和執行應用程式的方法,是一套技術體系和方法論,它還包括研發流程規範,軟體架構,基礎設施和工具集,為我們在基於的雲上開發提供了指導思想和最佳實踐。

只有按照雲原生的技術和管理方法,才能更好地把業務生於“雲”或遷移到雲平臺,從而享受“雲”的高效和持續的服務能力。

為了讓我們的產品更加符合雲原生,我們應該緊跟開源社群,順勢而為,迎合雲原生的理念,迎合社群的發展方向。

經邦大資料

作為雲原生時代下,大資料智慧微服務平臺的倡導者和積極實踐者,是國內領先專注於人的行為管理、分析和預測的軟體開發商和資料平臺運營服務商。透過兼收幷蓄國際最前沿的軟體技術和大資料解決方案,結合國內市場情況,自主創新研發在中國具有前瞻性和實用性的企業級一站式管理解決方案,為中國使用者構建具有先進管理理念, 靈活適用, 經濟高效的敏捷解決方案,幫助各行業 使用者從容應對瞬息萬變的市場,實現數字化原生管理。

經邦智慧分析微服務平臺致力於傳統企業的數字化轉型,以及各類微服務應用開發。傳統企業的數字化轉型,不僅是選擇產品,選擇技術,改變開發理念就能夠完成的簡單過程,還涉及到使用者自身的內部組織架構,乃至整個思想、思路的變革,是一個從內到外進行整體的變革過程。

經邦智慧利用雲原生技術,構建統一的雲化作業系統,幫助我們的客戶進行雲化/數字化/網際網路化的轉型需求,實現開發運維的一體化/微服務/敏捷開發的需求,也可以實現混合雲的部署需求,來滿足以應用為中心的開發運維體系。