之所以寫這篇文章是因爲公司的電商項目技術項目性能已經跟不上，項目結構也有着極大的問題，是個單體項目結構一個war包打天下，聚集了各種功能以及資源全都在一個工程裏面，而且前後端不分離還是用的jsp，更新迭代也很麻煩，更新一個管理後臺都要導致整個項目需要重啓，用戶端也會無法打開，啓動也很慢，要高達五分鐘。業務模塊不明確，魚龍混雜整個項目直接看上去無從下手，接手時候簡直想 *****。隨着業務擴展，代碼越來越複雜，代碼質量參差不齊(開發人員的水平不一),會讓你每次提交代碼 ，修改每一個小bug都是心驚膽戰的基本上每次能動前端我都不會改後端去重新部署項目，生怕一個小問題，全體宕機無法用。所以要解決一些現在存在的問題以及讓這個項目更長遠的運行，就有了這篇文章。但是不得不說SSM前後端不分離，遷移到springboot，目前對我來說是就是災難性的，也希望大佬看到不足和有問題之處及時伸出援手救救滿頭黑髮的孩子。
什麼是微服務
微服務核心就是把傳統的單機應用，根據業務將單機應用拆分爲一個一個的服務，徹底的解耦，每一個服務都是提供特定的功能，一個服務只做一件事,類似進程，每個服務都能夠單獨部署，甚至可以擁有自己的數據庫。這樣的一個一個的小服務就是微服務。
比如現在我們項目的有訂單、商品、支付、庫存、會員等模塊，如果沒有根據業務模型來拆分爲訂單服務、商品服務、支付服務、庫存服務、會員服務，像之前我們搞了抽獎活動定金可退，十幾天累積了2萬多筆訂單，這些訂單還需要退款，當我執行批量退款的時候，導致系統內存溢出，直接整個服務宕機打不開，像這樣的活動又不多，我不可能再去部署一臺專門退款，沒辦法就夜裏12點開始退款，商城掛上系統維護中的頁面。雖然解決了問題但不是最好的辦法，如果拆分了之後退款是一個單獨的服務，即便退款卡住了，整個系統核心功能例如下訂單，訪問，支付還是可以使用的，大概看起來就像下圖。
那麼看看目前我們項目現在的架構
單機架構
簡單暴力，不知道以前是怎麼想的pc和mobile這兩個模塊的接口基本上是一模一樣的唯一的區別就是jsp不一樣，我真的是吐了每次修改項目都得修改兩個地方，兩個要一起發佈，經常出現改了A忘了B的情況加上人員緊張力不從心啊，經常會出現各種各樣的小問題,而且是前後端不分離,提交文件膽戰心驚的,一般能不動就不動,除非大的模塊修改。如果併發的增加擴展也是縱向擴展
單機架構擴展
現在每次做電商活動，時間緊任務多，根本就不可能在現有的項目上迭代開發，目前是搭建了一個新的項目叫active,每次都在這個模塊迭代開發活動， 但是遇到一些和商城項目有關聯的業務邏輯還是要動一下，我基本上是本着能不動就不動的原則，但是例如這種下單即可抽獎，下單抽取半價車等活動，基於訂單的基礎，所以沒辦法還是要在原來的項目上進行迭代交互。一個是war包，一個是jar包，部署的算是環境吧，也不一致，一個單獨運行一個放在tomcat裏面運行，而且我一直懶得搞活動項目的高可用等等一些東西，一直都是讓他裸奔，不行就多跑幾。因爲之前特殊情況，舉辦了一個下單搶口罩的活動，項目直接雪山式崩塌服務器資源直接爆滿，整個項目全程宕機，做了一個很LOW的方法那就是直接限流，反正都是憑藉運氣，搶不到也不怪我了。其實更重要的是還出現了一個致命的問題就是Sql在本人能力之內極大優化之下，還出現了準確性的問題。活動持續了兩週每天就是看着什麼時候能搶完，當天把服務關了。每次活動持續時間也不長，就人工湊合湊合就過去了。還有一個致命的問題就是每次出現問題排查困難，那個日誌啊，簡直就是老太太穿棉襖一套又一套。
微服務架構
微服務架構
微服務擴展可以對某個模塊單獨擴展，例如訂單服務壓力過大，我就可以單獨添加訂單的機器，像之前如果有問題，需要重新從頭到尾的部署一套新的環境出來，現在都是用的docker部署方便了很多，當然後面微服務架構部署也是個麻煩事情，如果沒有運維還是要自己學習一下，這裏推薦k8s+docker+jenkis，這也是微服務的一個缺點吧，畢竟有利有弊還沒有百分百完美的事情
概念
①:將一個單一應用程序開發爲一組小型服務
②:每個服務運行在自己的進程中
③:服務之間通過輕量級的通信機制(http rest api)
④:每個服務都能夠獨立的部署
⑤:每個服務甚至可以擁有自己的數據庫
微服務以及微服務架構的是二個完全不同的概念，微服務強調的是服務的大小和對外提供的單一功能，而微服務架構是指把 一個一個的微服務組合管理起來，對外提供一套完整的服務。
微服務的優缺點
優點:
①：每個服務足夠小,足夠內聚，代碼更加容易理解,專注一個業務功能點(對比傳統應用，可能改幾行代碼 需要了解整個系統)
②: 開發簡單，一個服務只幹一個事情。（加入你做支付服務，你只要瞭解支付相關代碼就可以了）
③: 微服務能夠被2-5個人的小團隊開發，提高效率
④: 按需伸縮
⑤: 前後段分離, 作爲java開發人員，我們只要關係後端接口的安全性以及性能，不要去關注頁面的人機交互(H5工程師)根據前後端接口協議，根據入參，返回json的回參
⑥:一個服務可用擁有自己的數據庫。也可以多個服務連接同一個數據庫.
缺點:
①:增加了運維人員的工作量，以前只要部署一個war包，現在可能需要部署成百上千個war包 (k8s+docker+jenkis )
②:服務之間相互調用，增加通信成本
③:數據一致性問題(分佈式事物問題)
④:系能監控等,問題定位..........................
適用場景
合適
①:大型複雜的項目............(來自單體架構200W行代碼的恐懼)
②:快速迭代的項目............(來自一天一版的恐懼)
③:併發高的項目................(考慮彈性伸縮擴容的恐懼)
不合適
①:業務穩定，就是修修bug ，改改數據
②:迭代週期長髮版頻率一二個月一次.