微服務項目和單體系統的思考

微服務項目和單體系統的思考

單體系統

單體系統優點

所謂單體系統,就是項目啓動後只存在一個服務,對外也只提供一個URL訪問(這裏只討論Java),所有的模塊功能均在一個項目中。

  • 開發相對便利:架構起來方便,創建一個空的Maven項目,可以直接寫業務代碼,項目落地會更快,對於要搶佔市場,或者項目經理立了軍令狀的那種,建議單體系統先落地,然後考慮業務拆分,系統重構
  • 事務維護簡單:因爲是單體系統,在容器選擇Spring的情況下,事務控制就便利很多了,在充分了解了Spring的事務隔離級別之後,一個註解就OK了
  • 部署運維簡單:不論是SSH(Spring + Struts +Hibernate)、還是SSM(Spring + SpringMVC +Mybatis)抑或是現在的SpringBoot項目,一個Tomcat就可以部署了。
  • 集羣系統簡單:在單體系統訪問量達到一定的量,或者想短時間解決訪問量的問題,直接橫向增加一臺服務器,使用Nginx轉發一下,至少能提高70%-80%的性能

之前和另外一個公司的技術大佬做交流的時候,他有句話說的我覺得非常好,Java就是燒服務器的,如果能通過提升服務器服務器配置活着增加服務器數量解決的問題,爲什麼還要寫多餘的代碼呢。

單體系統缺點

說是單體系統的缺點其實也不準確,更像是瓶頸。

  • 業務隔離較弱:因爲單體系統的所有調用都在一起,也就是實際代碼落地的時候,各個業務是實際雜糅在一起的,很難保證業務隔離,基本上一個方法裏面會有大量的同步業務
  • 代碼維護成本:單體系統大量的代碼會使得代碼的維護成本相當高,筆者曾經維護過一套09年的代碼,稍微加一點東西都感覺要傷筋動骨
  • 擴展性比較差:項目落地後肯定會有大大小小的需求要改這改那,畢竟產品經理一般都是傻X,如果是自己寫的代碼還好,要是某位前輩留下的上古代碼,要再加一個新的功能,只能說加油吧
  • 併發訪問瓶頸:現在都在講高併發高可用,單體系統做到高可用還是很簡單的,但是在處理高併發的場景還是有瓶頸的,畢竟一個單體系統的承載量是有限的
  • 不利於模塊:假設一個下單系統,可能訂單和支付訪問量是比較高的,其餘的模塊訪問量可能並沒有那麼高,這種情況下其實更偏向於把訂單和支付做一個高可用,但是單體系統就做不到對某個模塊做垂直集羣,只能通過擴展整個系統的方式

微服務系統

微服務系統的優點

要開始一個微服務項目,首先要考慮的是,要解決哪些問題,不能單純的爲了用SpringCloud而用SpringCloud,要知道在引入一個新的技術的時候,會因此出現新的問題,就SpringCloud而言,項目的維護成本成倍增加,開發成本也會高很多。

  • 服務隔離: 根據微服務的最小服務原則,將業務可以系統化拆分,各個業務服務之間相對隔離
  • 方便擴展: 可以在註冊中心任意註冊其他業務模塊,如電商系統,最開始只有訂單模塊、結算模塊、支付模塊,現在想加入一個WMS倉儲系統,要怎麼加呢,如果式單體系統,肯定就是把原本已經複雜的系統,再硬生生嵌入一層倉儲系統,但是微服務系統則不然,可以直接單獨開放一個業務模塊,將新的倉儲模塊註冊到註冊中心,提供Feign接口即可
  • 集羣方便: 對於單個服務而言,想要做垂直集羣,只需要,更改模塊的啓動端口,在訪問的時候gateway會自動轉發

微服務系統的缺點

  • 開發門檻高: 微服務系統的開發門檻相對於單體系統來講,開發門檻還是要高一些的,開發者首先要理解微服務的各個組件,並能對其做基本配置和調優,其次要對分佈式系統有一定的瞭解,對CAP原則要有比較深刻的認識,知識要求更加全面,更加有深度
  • 服務之間調用繁雜: 服務隔離之後必然帶來的就是系統各個模塊之間調用的成本,把整個系統的鏈路都畫出來,你會發現那更像是一團毛線
  • 事務控制難度高: 其實這個問題並不是無服務的問題,這個問題的根本在分佈式事務,因爲服務隔離,更多的是去保證數據的最終一致性,所以單個事務就很難去準確的控制,更多的是通過數據補償的形式保證數據最終一致性
  • 維護成本高: 這個成本不是一般的高,可以說是普通單體系統的10倍以上,當業務模塊多到一定量的時候,系統在部署和運維上開銷會非常大

以上是本人在經歷了數個單體項目和微服務系統之後的一些思考,也僅作參考,希望對大家在技術選型的時候,整體架構的大方向是單體還是微服務有一點參考價值。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章