微服務開發攻略之淺析微服務架構

微服務開發攻略之淺析微服務架構

 

最近這些年，微服務非常火，那你有沒想過微服務的動機是什麼？其實，最重要的動機就是業務變化太快了。特別是移動網際網路出現以後，各種各樣的業務：共享單車、支付寶、微信支付等等，業務經歷著飛速的變革與創新，所以就要求底層的應用技術能夠支撐得上業務的快速變化。

我們看一下應用架構的變遷，其實也是從另一個角度來印證上文說的“快”。

第一代是單體架構，當然它有很多，例如緊耦合、封閉架構等各種各樣的問題。第二代是 SOA架構，可能大型企業級的應用裡面會比較多，提供了很多種支援，實際上我們看到SOA架構的時候，它已經強調松耦合了。那麼他強調這一點是為了什麼？其中一點就是因為快（當然不是僅僅為了快）。到現在第三代微服務架構，它實際上是變得更加靈活了。在業務變化非常快速的背景之下，微服務架構是一個非常好的解決方案，微服務的核心——敏捷、靈活、精準彈性。微服務架構出現的最大的意義是不斷地提高交付效率，縮短交付週期。

微服務最有名的人—— Martin Fowler，在2015年提出了微服務的概念（實際上2009年Netflix就已經開始實踐微服務了，但是當時沒有微服務一詞）。2015年Martin Fowler明確的提出了微服務的概念並對它進行了一些比較清晰的定義，最主要的就是：小、獨、輕、松。就是說微服務要小，模組邊界要更清晰，支援獨立部署獨立演進，每個微服務都應該可以獨立部署，獨立演進，獨立升級的。另外允許技術多樣性，就是在微服務構成的一個整體的應用系統裡面，每一塊的業務要用你最適合的技術去實現，而不是都統一用一種語言去實現，這也是微服務非常重要的一個特點。

所有事情都有兩面性，那微服務也不是隻有好處沒有壞處的，它也會帶來問題。其實很明顯，例如，從運維人員的角度來看，原來只需要運維一個應用；把它拆開後，就需要運維多個應用，複雜性和難度一定是增加的。從開發人員的角度來看，原來寫程式的時候，單體應用，方法之間的呼叫就可以解決很多業務的處理了；變成分散式以後，就要遠端呼叫，不能用簡單的程式內的呼叫了。用遠端呼叫它就會出現一些問題，比如會變慢、可靠性比程式內部的差等等。那開發人員就要去處理這些問題，要去為這些問題做準備。還有一點也是非常重要的，就是資料一致性的問題。原來在單體應用裡面，可以用資料庫保持資料的一致性（或者說用資料庫的事務去保證資料的一致性）；但是到分散式系統以後，突然發現這種方式不行了。因為在微服務架構裡面提倡的是資料分開，就是說每一個微服務都會有自己獨立的資料庫。 Martin Fowler也講了允許技術的多樣性，到資料這一層也要用最合適的資料庫技術去構建單獨的微服務。原來保證資料一致性都是關係型資料庫，直接用事物就好了。但是到了微服務就不一樣，可能有些微服務用的是關係型資料庫，但有些微服務用的是非關係型的資料庫。所以在這樣的前提下，去保證整個系統的資料一致性，也是帶來了很大的挑戰的。

以上大致介紹了什麼是微服務架構，它有什麼樣的特點，又有什麼樣的優勢和挑戰。想了解更多微服務相關內容嗎，華為雲學院（ https://edu.huaweicloud.com/ ）

已上線多門微服務相關課程，從基礎知識入門，到開發第一個微服務，到微服務的上線、治理，帶你一站式攻克微服務，敏捷開發微服務應用，快來報名學習吧。