微服務開發攻略之淺析微服務架構
最近這些年，微服務非常火，那你有沒想過微服務的動機是什麼？其實，最重要的動機就是業務變化太快了。特別是移動互聯網出現以後，各種各樣的業務：共享單車、支付寶、微信支付等等，業務經歷着飛速的變革與創新，所以就要求底層的應用技術能夠支撐得上業務的快速變化。
我們看一下應用架構的變遷，其實也是從另一個角度來印證上文說的“快”。
第一代是單體架構，當然它有很多，例如緊耦合、封閉架構等各種各樣的問題。第二代是SOA架構，可能大型企業級的應用裏面會比較多，提供了很多種支持，實際上我們看到SOA架構的時候，它已經強調鬆耦合了。那麼他強調這一點是爲了什麼？其中一點就是因爲快（當然不是僅僅爲了快）。到現在第三代微服務架構，它實際上是變得更加靈活了。在業務變化非常快速的背景之下，微服務架構是一個非常好的解決方案，微服務的核心——敏捷、靈活、精準彈性。微服務架構出現的最大的意義是不斷地提高交付效率，縮短交付週期。
微服務最有名的人——Martin Fowler，在2015年提出了微服務的概念（實際上2009年Netflix就已經開始實踐微服務了，但是當時沒有微服務一詞）。2015年Martin Fowler明確的提出了微服務的概念並對它進行了一些比較清晰的定義，最主要的就是：小、獨、輕、鬆。就是說微服務要小，模塊邊界要更清晰，支持獨立部署獨立演進，每個微服務都應該可以獨立部署，獨立演進，獨立升級的。另外允許技術多樣性，就是在微服務構成的一個整體的應用系統裏面，每一塊的業務要用你最適合的技術去實現，而不是都統一用一種語言去實現，這也是微服務非常重要的一個特點。
所有事情都有兩面性，那微服務也不是隻有好處沒有壞處的，它也會帶來問題。其實很明顯，例如，從運維人員的角度來看，原來只需要運維一個應用；把它拆開後，就需要運維多個應用，複雜性和難度一定是增加的。從開發人員的角度來看，原來寫程序的時候，單體應用，方法之間的調用就可以解決很多業務的處理了；變成分佈式以後，就要遠程調用，不能用簡單的進程內的調用了。用遠程調用它就會出現一些問題，比如會變慢、可靠性比進程內部的差等等。那開發人員就要去處理這些問題，要去爲這些問題做準備。還有一點也是非常重要的，就是數據一致性的問題。原來在單體應用裏面，可以用數據庫保持數據的一致性（或者說用數據庫的事務去保證數據的一致性）；但是到分佈式系統以後，突然發現這種方式不行了。因爲在微服務架構裏面提倡的是數據分開，就是說每一個微服務都會有自己獨立的數據庫。Martin Fowler也講了允許技術的多樣性，到數據這一層也要用最合適的數據庫技術去構建單獨的微服務。原來保證數據一致性都是關係型數據庫，直接用事物就好了。但是到了微服務就不一樣，可能有些微服務用的是關係型數據庫，但有些微服務用的是非關係型的數據庫。所以在這樣的前提下，去保證整個系統的數據一致性，也是帶來了很大的挑戰的。
以上大致介紹了什麼是微服務架構，它有什麼樣的特點，又有什麼樣的優勢和挑戰。想了解更多微服務相關內容嗎，華爲雲學院（https://edu.huaweicloud.com/）
已上線多門微服務相關課程，從基礎知識入門，到開發第一個微服務，到微服務的上線、治理，帶你一站式攻克微服務，敏捷開發微服務應用，快來報名學習吧。