公司要轉型微服務,真的有必要么?

今天參加了DevOps的國際峰會,一整天聽了兩個專題,分別是和微服務相關的,以及和kubernetes相關的,現將聽后的一些心得記錄下來,分享給大家。

文/謙益

這篇主要是給大家分享微服務相關的。

現在,在互聯網圈子里,不知道何時微服務這個概念已經深入到了我們圈內的各個角落,似乎如果不趕上這個潮流,公司的產品就將被淘汰了。

這個專場開場時,老師給我們說了個他的一段經歷。

一天他鄰居問他:“你的微服務課程我可以去聽么?”
老師很是驚訝,說:“你做微商的怎么這么好學呀,你知道啥是微服務么?”
鄰居說:“微服務不是為微商服務的么?”

當然這略帶有點喜劇性了,不過對于微服務,真的是和我們理解的那樣么?我在聽這場分享之前我一直認為,微服務不就是把業務按照功能模塊切割,讓他獨立出來么?

聽完這場分享,對微服務的定義,有了全新的認識。


01 微服務不是簡單的模塊切割

目前業內對微服務存在的誤解有很多,這里ThoughtWorks的架構師和堅老師給我們列出來幾點:

  • 構建HTTP服務,實用Docker容器運行它,并且用Kubernets做集群管理,就是微服務
  • 使用API Gateway和服務發現以及服務registry,這就是微服務
  • 使用Spring Boot框架構建http服務,并使用Netflix OSS,這就是微服務
  • 使用Azure Service Fabric 構建并且運行應用程序,這就是微服務
  • 構建輕量級的RESTful API,這就是微服務
  • 有很多框架聲稱是微服務框架。使用這些框架的任意一種來構建應用程序,這就是微服務

看完這些,我就有點蒙圈了,那到底怎樣的才算微服務呢?下面是老師對微服務的一個概括:

微服務架構是一種架構模式,它提倡將單一應用程序劃分成一組小的服務,每個服務運行在其獨立的進程中,服務間采用輕量級的通信機制互相溝通(通常是基于HTTP協議的RESTful API)。每個服務都圍繞著具體業務進行構建,并且能夠被獨立的部署到生產環境、類生產環境等

同時和堅老師給我們分享了微服務具有以下幾點特點:

  • 通過服務進行組件化
  • 圍繞業務能力組織
  • 做產品而不是做項目
  • 只能端點與傻瓜管道
  • 去中心化地治理技術
  • 去中心化地管理數據
  • 基礎設施自動化
  • 容錯設計
  • 演進式設計

我這里的理解是微服務其實是圍繞業務能力組織進行劃分的一整套服務集群,但是該怎么劃分呢?他的粒度是什么呢?


02 別一不小心把微服務切成了小的單體

假設有一天你的系統已經進行了“微服務”改造,由于你的業務發展,新的需求如潮水般涌來,漸漸的發現某些“微服務”開始慢慢的膨脹起來。

發現膨脹的“微服務”有一部分業務又需要拆分了,而且這個服務內部還高度耦合,這不就又變成了,拆分之前的服務了么?

你拆分成的不是微服務,而是一個小的單體。

關于怎么拆分微服務,和堅老師給我推薦了一個叫DDD服務設計的思想:

要求我們從業務視角去分離復雜度,最終目標都是為最求高響應力。

讓業務架構和系統架構形成綁定關系,從而當我們去響應業務變化調整業務架構時,系統架構的改變是隨之而發的。

雖然短短的兩句話,但是要理解做好,真不是那么容易,還待深入學習。

目前微服務只存在一個概念性的階段,要想將我們現有的服務切分成微服務,按照什么標準進行切分,不同的行業,不同的業務場景,將是不同的,這是一個難題?

當我們辛辛苦苦的把業務切成了一個一個小的服務在跑時,如果哪天業務發展,發現這兩個服務還是和在一起跑比較好,這時,你將面臨的不是單單的把兩個代碼合在一起這么簡單。

代碼上的沖突,修改上下游的依賴,部署架構都將是一個挑戰。

微服務的合并,比拆分更難。


03 一個完整的微服務離不開完善的自動化運維

當我們的項目被拆分成了微服務在線上跑了,我們的開發看到的將不再是一整個業務的代碼,而是一個一個小的模塊服務。

我們的開發將面臨:我們得把整體的所有服務了解個遍,或者相關的服務模塊了解完。

如果不能了解完,將會出現:在版本迭代時,我們修改的代碼,能保證這個服務上沒問題,不能保證上線后對其他的業務不會有影響。

對于這個問題,微軟的MVP陳鋒逸老師提出了一個建議,借助一些代碼即架構的工具來彌補這塊。

微服務落地,我們還將面臨,我們的服務散落在各個地方,運維的同事將怎么進行監控,怎么知道此時此刻哪個服務掛了,哪個服務超載了,超載時我們怎么進行擴容,這都是我們要解決的問題。

還有,如果我們辛辛苦苦做成了微服務,在版本發布時,怎么保證線上所有容器的版本一直性,也是要解決的問題。

這一系列的問題就涉及到可持續性交付這塊了,從開發提交代碼,到測試,到構建,再到測試用例的覆蓋,最后到生產這一連貫的工作,怎么讓他們自動化?如果做不到自動化,那投入的成本將可能是傳統的架構的N倍。


04 結束語

我不是一個架構師,只是一個小小的開發者,所有行文都是按照一個開發者的角度結合今天老師講的所寫,所以可能有諸多不恰當的措詞,歡迎指正。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 230,563評論 6 544
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 99,694評論 3 429
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 178,672評論 0 383
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,965評論 1 318
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 72,690評論 6 413
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 56,019評論 1 329
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 44,013評論 3 449
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 43,188評論 0 290
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 49,718評論 1 336
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 41,438評論 3 360
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,667評論 1 374
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 39,149評論 5 365
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,845評論 3 351
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 35,252評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,590評論 1 295
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 52,384評論 3 400
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 48,635評論 2 380