用普通話說微服務系列（一） 單體應用到微服務的進化

 　　轉發時請註明原創做者及地址，不然追究責任。原創：alunchen

從工做體驗切入

開始部署應用             

      在好久好久之前，開發與部署web應用時，一開始都是很開心地寫完‘整個’應用，以包或者文件夾等方式部署到服務器上。在java中，用war包部署到tomcat服務器；在.net中，在IIS管理器中指定文件夾。應用就這樣愉快地運行着。

噩夢開始前兆             

      忽然，開發的應用是一個有市場潛力的應用，或者客戶想開發2期，3期...... 這樣，應用越變越大、項目上線了、修改bug變得愈來愈吃力、之前開發此功能的同事走了，修改bug用添加代碼的方式修改、項目啓動愈來愈慢。

      就這樣，項目支撐了幾年...

噩夢開始前的準備    

      技術負責人忽然發現，項目支撐不了多長時間了。而且有其它項目可用到咱們開發的功能組件，例如圖片處理功能。

      技術負責人很負責地把應用拆分。分紅不一樣的服務開發的形式。例如咱們開發的是一個商城平臺。技術負責人把商城平臺拆分紅：圖片處理服務、交易服務、用戶管理服務、商城數據服務（包括商品、類別等）。這時候，系統開發者們很驕傲地看到此應用拆分紅的服務能夠跑不少年。

架構的追求               

      商城拆分的服務跑得很完美，可是隨着服務的添加與拆分，架構師看到了重複的工做與服務存在不合理的架構。

      什麼樣的重複工做呢？當添加一個服務時，手動添加VM來部署、前端又要添加請求新域名IP的服務。

      而且不合理的架構：1）多個服務使用同一個數據庫，可能致使數據庫壓力過大。2）服務的粒度區分不明顯，有大有小。3）服務沒有同一的認證中心。4）服務動態修改實例數很麻煩。

      針對上面全部的問題，微服務設計思想，就提出了。

 

微服務開播啦！

      什麼是微服務？微服務是一種架構設計，集合了多個概念而成。由於微服務要運行在分佈式環境，提倡自動化，因此微服務有不少專業的實現名詞。包括服務發現、熔斷限流、服務網格、API網關等。這些個名詞，都會用普通話來開篇敘說。

      微服務能夠單獨跑在一個VM或者Docker上。而且有本身的專門數據庫。這個很好理解，微服務提倡解耦。每一個微服務能夠鏈接本身的數據庫，而且此數據庫是獨立存在於其它微服務。其它微服務想要訪問數據的時候，能夠訪問我微服務的API便可。

 

微服務能夠編寫本身的編程語言。甚至於，在同‘一堆’微服務裏，商品微服務用C#、用戶微服務用Java、購物車微服務用PHP。多麼的‘解耦’啊！

 

      微服務的粒度提倡不要太少。有人說，微服務的粒度控制在10個類之內，每一個類100行代碼之內。個人天！這個按代碼區分的微服務粒度也過低了！反而引發服務的過分調用。若是平時你要下單購買一個商品時的流程，只須要訪問訂單、商品、支付微服務。可是你區分的太少，可能訪問的微服務變成了十幾個，甚至上百。這樣想一下性能也過低了吧！由於每一個微服務運行在單獨的進程裏。

告誡                  

      在選擇使用微服務前，須要考慮團隊是否有相應的技術。開發微服務須要的技術人員技術相應較高，而且須要理解微服務的一些基本原理，除非公司已經有了一套完整的微服務框架，開發人員只須要在上面像單體應用地開發。

      微服務開發前期須要的週期會相應的增長，甚至是增長几倍。

      微服務須要有相應程序的運維團隊去運維你的微服務。若是公司有本身的運維一體化工具，則省去了這個建隊需求。

      因此，在使用微服務前，考慮周到，不要盲目地追求使用。最後你可能項目延期、性能比單體應用還慢！

期待                    

      微服務，還有一段很長的路要走。就在今年2018，微服務提出了2.0版本，服務網格。期待微服務整個體系慢慢完善統一塊兒來。

 

微服務的好處

1）數據源隔離，達到解耦的目的。每一個微服務有本身的數據源，若是須要遷移微服務、加大微服務實例數都很是簡單，不用再考慮數據切分的事情了。

2）統一的認證中心、服務發現、服務網關。統一了分佈式開發的工具、設計思想。

3）系統越大，相應地開發週期不會線性的增加。

微服務的劣處

1）微服務是分佈式開發，因此開發變得異常複雜。分佈式系統存在着兩大難題，一個是分佈式事務，另一個是分佈式鎖。

2）微服務粒度越細，性能越低。

3）若是沒有自動化部署工具，微服務部署變得一場複雜。

 

能夠關注本人的公衆號，多年經驗的原創文章共享給你們。