鎮樓小姐姐
36份一線互聯網Java面試電子書
84個Java稀缺面試題視頻
什麼是微服務？
微服務是很小的，但是又能夠獨立部署的服務。
微服務的優點
1.不同的服務可以使用不同的語言和技術來實現
2.提供服務可用性，當其中一個服務不能正常工作，可以通過多實例或者服務降級來維持著
3.擴展性好，某些特別需要資源的服務可以專門提供更多的資源來支撐
4.部署簡單，如果是單體應用，修改一行代碼都需要整個工程重啟
5.因為微服務的每個服務都很小，所以修改起來十分輕鬆，並且重構都是簡簡單單的事情
微服務的缺點
1.技術門檻提高了，因為你要面對分佈式的問題
2.總體部署也變得複雜了，因為你多個服務可能需要不同的環境，你還要為其提供必需的運行環境
3.需要考慮服務間通訊的可靠性和穩定性，網絡並不是十分可靠的
4.服務數量一多，如果依賴錯綜複雜的話，絕對是一個災難
嘗試微服務
如果你看了上面的缺點，覺得啟用微服務的好處大於缺點的話，可以嘗試開始微服務。在決定開始微服務之前，首先先好好考慮一下自己的技術團隊有沒有下面提及的能力。
- 有一定的運維能力，最不濟也會寫shell腳本半自動部署
- 有一定的架構能力，不然如何拆分成一個又一個的服務，服務拆分邊界的定義可是一件技術活
- 有足夠的人力（上微服務的前期投入肯定比不使用微服務大）
如果看到這裡，依舊覺得微服務還是必須的話，那麼，我必須先跟你說一下我親身經歷過微服務導致的事故，當然不是說我不提倡用微服務，而是儘可能告知一下使用微服務可能遇到的問題。
微服務帶來的事故
當時年少無知，初聽到微服務，覺得這是一種高大上的開發技術，並且持著自己會docker，會折騰一下k8s，所以果斷把一個項目拆成若干個服務。
真別說，一開始開發的時候，一個同學只需要2，3天獨立寫完一個服務。因為用docker部署，所以我準備好各種環境的鏡像即可，然後通過k8s編排應用，有自己的CI管理應用（這個CI經過半年斷斷續續的迭代，正準備開源出來），部署也是一分鐘解決了。那成就感刷刷刷的就上去，但是好景不長呀。
第一次事故出現在集群身上，鏡像沒優化好，服務擴充得太快，日誌收集沒做，直接導致服務可用性還比不上以前，線上查錯也複雜了。好不容易，把這些都優化了，但是問題才陸續有來。（基於docker的部署，小心磁盤不夠用和妥善收集日誌）
第二次事故出現在服務之間的通訊上，基於http的試了，基於rabbitmq的試了。也許你會說，這有什麼問題呀。第一個，服務間的通訊導致代碼量增加了，那麼意味著我們的同學要寫更多的代碼了。工作量還是其中一個問題，不同環境還要調用不同環境裡面的服務。本地開發如何調用其他服務呢？（值得思考的問題）
事故還沒完，當你做ABtest的時候，做灰度發佈的時候，調用鏈有幾層的時候，如何處理？自己實現，直接蒙圈。用現成的，上服務註冊中心，這是技術門檻嗖嗖嗖的上去了，小團隊真心折騰不起來。
經歷微服務事故之後的感想
以前的我，喜歡用shell實現半自動化部署。只從經歷了一次微服務模式的應用開發之後，我喜歡上CI了（為什麼我自己造一個CI，因為我沒發現哪個CI可以簡簡單單的用，又能隨時回退到任意版本）。
發佈不中斷服務，只需要滾動發佈就好了，k8s和docker swarm一個服務多個實例，選擇正確的更新模式。
docker真是一個好玩意，每個版本一個鏡像，想回滾就回滾（但是回滾風險自行考慮）。
開始你的微服務之旅
我上面說了這麼多唬人的話，你是不是有點想放棄微服務呢？不，不能如此想。現在我用我短短的微服務開發經驗來談論一下，其實每個人都可以使用微服務的架構設計。
首先，還是按著以前的模式開發。但是一些不會經常變化的，又是公司層面或者團隊層面公用的服務抽離出來。例如發送短信，郵件服務，用戶登錄服務。
接著，是不是發現支付系統，應用消息推送系統也可以拆出來，成為一個微服務呢？
把基礎服務都拆成微服務之後，是不是意猶未盡，還想拆拆拆。別慌，滿足你。這個時候，你可以根據業務為邊界拆分，只要你拆出來的服務僅僅是給其他服務調用，不依賴其他服務，你就可以勇敢的拆。
當你拆的服務越多，你的運維壓力就越大，記得多使用工具和找厲害的運維提供必要的技術支持。另外我聽來的一個觀點是，一個微服務，你能2星期內重構掉，大小才是合理的。
寫在最後
別想著看完這文章，你就可以在微服務領域為所欲為。看完，有所感悟就好。沒有收穫，也別吐槽我。
如果你想你的團隊hold住微服務架構，那麼請先聘請一個技術過硬的技術人員和經驗豐富的架構師來設計開發。
我準備開源我自己在用的CI出來，但是呢，還有一些優化的點還沒處理好，請耐心等待。
我的GitHub地址是： https://github.com/yubang，
閱讀更多 李紅 的文章
