微服務架構越來越火，有必要學習一下。
軟件開發過程中碰到什麼問題
一個簡單的應用會隨着時間推移逐漸變大。在每次的sprint中，開發團隊都會面對新“故事”，然後開發許多新代碼。幾年後，這個小而簡單的應用會變成了一個巨大的怪物。
一旦你的應用變成一個又大又複雜的怪物，那開發團隊肯定很痛苦。敏捷開發和部署舉步維艱，其中最主要問題就是這個應用太複雜，以至於任何單個開發者都不可能搞懂它。因此，修正bug和正確的添加新功能變的非常困難，並且很耗時。另外，團隊士氣也會走下坡路。如果代碼難於理解，就不可能被正確的修改。最終會走向巨大的、不可理解的泥潭。
單體式應用也會降低開發速度。應用越大，啓動時間會越長。比如，最近的一個調查表明，有時候應用的啓動時間居然超過了12分鐘。某些應用需要40分鐘啓動時間。如果開發者需要經常重啓應用，那麼大部分時間就要在等待中渡過，生產效率受到極大影響。
另外，複雜而巨大的單體式應用也不利於持續性開發。今天，SaaS應用常態就是每天會改變很多次，而這對於單體式應用模式非常困難。另外，這種變化帶來的影響並沒有很好的被理解，所以不得不做很多手工測試。那麼接下來，持續部署也會很艱難。
單體式應用在不同模塊發生資源衝突時，擴展將會非常困難。比如，一個模塊完成一個CPU敏感邏輯，應該部署在AWS EC2 Compute Optimized instances，而另外一個內存數據庫模塊更合適於EC2 Memory-optimized instances。然而，由於這些模塊部署在一起，因此不得不在硬件選擇上做一個妥協。
單體式應用另外一個問題是可靠性。因爲所有模塊都運行在一個進程中，任何一個模塊中的一個bug，比如內存泄露，將會有可能弄垮整個進程。除此之外，因爲所有應用實例都是唯一的，這個bug將會影響到整個應用的可靠性。
最後，單體式應用使得采用新架構和語言非常困難。比如，設想你有兩百萬行採用XYZ框架寫的代碼。如果想改成ABC框架，無論是時間還是成本都是非常昂貴的，即使ABC框架更好。因此，這是一個無法逾越的鴻溝。你不得不在最初選擇面前低頭。
總結一下：一開始你有一個很成功的關鍵業務應用，後來就變成了一個巨大的，無法理解的怪物。因爲採用過時的，效率低的技術，使得僱傭有潛力的開發者很困難。應用無法擴展，可靠性很低，最終，敏捷性開發和部署變的無法完成。
微服務解決應用複雜性
面對上面的問題，通過採用微服務解決了上述問題。其思路不是開發一個巨大的單體式的應用，而是將應用分解爲小的、互相連接的微服務。
一個微服務一般完成某個特定的功能，比如下單管理、客戶管理等等。每一個微服務都是微型六角形應用，都有自己的業務邏輯和適配器。一些微服務還會發布API給其它微服務和應用客戶端使用。其它微服務完成一個Web UI，運行時，每一個實例可能是一個雲VM或者是Docker容器。
運行時，行程管理服務由多個服務實例構成。每一個服務實例都是一個Docker容器。爲了保證高可用，這些容器一般都運行在多個雲VM上。服務實例前是一層諸如NGINX的負載均衡器，他們負責在各個實例間分發請求。負載均衡器也同時處理其它請求，例如緩存、權限控制、API統計和監控。
這種微服務架構模式深刻影響了應用和數據庫之間的關係，不像傳統多個服務共享一個數據庫，微服務架構每個服務都有自己的數據庫。另外，這種思路也影響到了企業級數據模式。同時，這種模式意味着多份數據，但是，如果你想獲得微服務帶來的好處，每個服務獨有一個數據庫是必須的，因爲這種架構需要這種鬆耦合。
到底什麼是微服務
接下來我們來看看到底什麼是微服務。實際上微服務本身並沒有一個嚴格的定義，不過從很多人的反饋來看，大家都達成了這樣一個共識：微服務是一種簡單的應用，大概有10到100行代碼。我知道使用代碼行數來比較實現其實很不靠譜，因此你能理解這個意思就行，不必過分拘泥於細節。不過有一點需要注意，那就是微服務通常都是很小的，甚至是微型的。這意味着你不會在大型框架上看到很多小服務，這是不切實際的。簡單與輕量級是當今的主流。諸如Sinatra、Webbit、Finagle與Connect等小型框架在將你的代碼包裝到一個薄薄的通信層這方面做得剛剛好。
從物理角度來說，這些服務都很小，你可以在同一臺機器上運行大量服務，不必擔心內存或是資源等問題。重申一遍，基於大型框架的簡單庫將會取得最後的勝利，你會發現對第三方庫的依賴越來越少。
這種服務層上的解耦還提供了另外一個有趣兒的選擇。我們將很多老舊應用的複雜性推到了基礎設施層，不再受限於單個技術棧或是語言了。我們現在可以發揮出任何技術棧或是語言的優勢。
你不會看到任何基於微服務的架構是託管在應用服務器上的，這是關鍵。本質上，微服務是自我託管的，他們獲取一個端口然後監聽。這意味着你將失去典型的企業應用服務器所帶來的很多好處，服務需要提供這些必要的功能（性能度量、監控等等）。
微服務的通信
服務之間該如何通信呢？這個問題是無法通過一個簡單的答案解決的，甚至在單個解決方案中也是難以做到的。最基本的答案就是通過HTTP公開所有服務，然後以JSON作爲數據交換格式。服務探測（一個服務是如何找到另一個服務的）可以很簡單，只需將端點細節信息放到配置文件中即可（硬編碼也行）。
你可能會發現在某些情況下，一個完整事務中對JSON負載的序列化與反序列化的代價會造成系統瓶頸。也許JSON並不適合，你可能需要使用別的協議，如Protobuf等。
不過硬編碼的URL會導致耦合。在分層應用中，這是有意義的，不過對於基於服務的架構來說，這意味着你不能再被這種潛在的限制所約束。服務之間的某些通信可以是完全解耦的，事實上，有些服務可以隨意發佈事件或是數據。他們只是將其扔出去（比如說消息總線），也許有一天出現了某個服務，然後開始監聽了。此外，也許系統的某些部分會以批量/離線的流程進行運作，他們可能會在幾小時後才從隊列中取出消息。微服務架構可以實現這種靈活性而無需修改整個架構。
微服務的部署
部署一個微服務應用也很複雜，一個分佈式應用只需要簡單在複雜均衡器後面部署各自的服務器就好了。每個應用實例是需要配置諸如數據庫和消息中間件等基礎服務。相對比，一個微服務應用一般由大批服務構成。例如，根據Adrian Cockcroft，Hailo有160個不同服務構成，NetFlix 有大約600個服務。每個服務都有多個實例。這就造成許多需要配置、部署、擴展和監控的部分，除此之外，你還需要完成一個服務發現機制，以用來發現與它通訊服務的地址(包括服務器地址和端口)。傳統的解決問題辦法不能用於解決這麼複雜的問題。接續而來，成功部署一個微服務應用需要開發者有足夠的控制部署方法，並高度自動化。
一種自動化方法是使用PaaS服務，例如Cloud Foundry。 PaaS給開發者提供一個部署和管理微服務的簡單方法，它把所有這些問題都打包內置解決了。同時，配置PaaS的系統和網絡專家可以採用最佳實踐和策略來簡化這些問題。另外一個自動部署微服務應用的方法是開發對於你來說最基礎的PaaS系統。一個典型的開始點是使用一個集羣化方案，比如配合Docker使用Mesos或者Kubernetes。後面的系列我們會看看如何基於軟件部署方法例如NGINX，可以方便的在微服務層面提供緩存、權限控制、API統計和監控。
監控與度量
分層解決方案的組件出現問題時不會銷聲匿跡，要麼是編譯失敗，要麼是遇到問題時拋出異常（除非你將拋出的異常隱藏掉了）。在基於服務的方式中，有的服務可能出現了問題，而其他服務則會很容易發現問題（特別是在pub/sub模型中）。這意味着我們必須要能對服務進行監控和編排。事實上，只知道服務還能用是不夠的，服務是不是還能提供業務價值？還能否繼續使用？它是可靠交易的瓶頸麼？
監控總是非常重要的事情，對於基於服務的架構來說更是如此，因爲這時出現的失敗並不容易被發現。JVM世界中的Metrics與Ostrich等庫不僅可以收集度量信息，還提供了與Nagios和Ganglia等服務的集成，可以將數據發送給他們。
微服務的測試
對於基於微服務架構的系統來說，測試服務並沒有什麼特殊之處，不過我這裏要強調的是你不必再對每個服務使用完整的測試套件了。因爲一個服務只做一件事，因此引入系統Bug的機率明顯降低了，這要歸功於基於服務的系統的天生的行爲。
微服務架構的好處
微服務架構模式有很多好處。首先，通過分解巨大單體式應用爲多個服務方法解決了複雜性問題。在功能不變的情況下，應用被分解爲多個可管理的分支或服務。每個服務都有一個用RPC-或者消息驅動API定義清楚的邊界。微服務架構模式給採用單體式編碼方式很難實現的功能提供了模塊化的解決方案，由此，單個服務很容易開發、理解和維護。
第二，這種架構使得每個服務都可以有專門開發團隊來開發。開發者可以自由選擇開發技術，提供API服務。當然，許多公司試圖避免混亂，只提供某些技術選擇。然後，這種自由意味着開發者不需要被迫使用某項目開始時採用的過時技術，他們可以選擇現在的技術。甚至於，因爲服務都是相對簡單，即使用現在技術重寫以前代碼也不是很困難的事情。
第三，微服務架構模式是每個微服務獨立的部署。開發者不再需要協調其它服務部署對本服務的影響。這種改變可以加快部署速度。UI團隊可以採用AB測試，快速的部署變化。微服務架構模式使得持續化部署成爲可能。
最後，微服務架構模式使得每個服務獨立擴展。你可以根據每個服務的規模來部署滿足需求的規模。甚至於，你可以使用更適合於服務資源需求的硬件。比如，你可以在EC2 Compute Optimized instances上部署CPU敏感的服務，而在EC2 memory-optimized instances上部署內存數據庫。
微服務架構的不足
Fred Brooks在30年前寫道，“there are no silver bullets”，像任何其它科技一樣，微服務架構也有不足。其中一個跟他的名字類似，『微服務』強調了服務大小，實際上，有一些開發者鼓吹建立稍微大一些的，10-100 LOC服務組。儘管小服務更樂於被採用，但是不要忘了這只是終端的選擇而不是最終的目的。微服務的目的是有效的拆分應用，實現敏捷開發和部署。
另外一個主要的不足是，微服務應用是分佈式系統，由此會帶來固有的複雜性。開發者需要在RPC或者消息傳遞之間選擇並完成進程間通訊機制。更甚於，他們必須寫代碼來處理消息傳遞中速度過慢或者不可用等局部失效問題。當然這並不是什麼難事，但相對於單體式應用中通過語言層級的方法或者進程調用，微服務下這種技術顯得更復雜一些。
另外一個關於微服務的挑戰來自於分區的數據庫架構。商業交易中同時給多個業務分主體更新消息很普遍。這種交易對於單體式應用來說很容易，因爲只有一個數據庫。在微服務架構應用中，需要更新不同服務所使用的不同的數據庫。使用分佈式交易並不一定是好的選擇，不僅僅是因爲CAP理論，還因爲今天高擴展性的NoSQL數據庫和消息傳遞中間件並不支持這一需求。最終你不得不使用一個最終一致性的方法，從而對開發者提出了更高的要求和挑戰。
測試一個基於微服務架構的應用也是很複雜的任務。比如，採用流行的Spring Boot架構，對一個單體式web應用，測試它的REST API，是很容易的事情。反過來，同樣的服務測試需要啓動和它有關的所有服務(至少需要這些服務的stubs)。再重申一次，不能低估了採用微服務架構帶來的複雜性。
另外一個挑戰在於，微服務架構模式應用的改變將會波及多個服務。比如，假設你在完成一個案例，需要修改服務A、B、C，而A依賴B，B依賴C。在單體式應用中，你只需要改變相關模塊，整合變化，部署就好了。對比之下，微服務架構模式就需要考慮相關改變對不同服務的影響。比如，你需要更新服務C，然後是B，最後纔是A，幸運的是，許多改變一般隻影響一個服務，而需要協調多服務的改變很少。
微服務總結
1、微服務是一種新的架構思路，從傳統的SOA中發揚出來，摒棄了傳統SOA重型、低效的弊端。
2、微服務更多的是一種架構理念，服務的劃分沒有一個強規則，遵循服務自治，數據自有即可。實施微服務同時也在踐行新的敏捷、devops等開發理念。
3、微服務適合複雜應用，微服務就是爲解耦複雜應用誕生。複雜是業務邏輯複雜，並不是資源消耗多。所以微服務更適合應用層業務的實施，而不是底層平臺，如存儲、數據庫、OS等。
4、微服務需要發展和配合更多的分佈式監控、部署、測試、定位工具，架構的解耦同時引入了分佈式的複雜性。
參考文獻
1、微服務架構解析http://www.infoq.com/cn/news/2013/12/micro-service-architecture/
2、詳述微服務架構的優勢與不足http://www.d1net.com/cloud/news/351811.html