微服務項目和單體系統的思考
單體系統
單體系統優點
所謂單體系統,就是項目啓動後只存在一個服務,對外也只提供一個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倍以上,當業務模塊多到一定量的時候,系統在部署和運維上開銷會非常大
以上是本人在經歷了數個單體項目和微服務系統之後的一些思考,也僅作參考,希望對大家在技術選型的時候,整體架構的大方向是單體還是微服務有一點參考價值。