微服務架構中的 “微”體現了其核心要素,?
即服務的微型化,就是每個服務微小到只需專注做好一件事。?
這件事緊密圍繞業務領域,形成高度內聚的自治性。

以前做大型應用系統,大都采用模塊化的分層式架構,?
所有的業務邏輯代碼最終會打進一個代碼庫中統一部署。

這種應用架構的問題是,全部開發人員會共享一個代碼庫?
不同模塊的邊界模糊,實現高內聚、松耦合極其困難。

如果你接手過這類應用的遺留系統,嘗試去做重構改進時,肯定碰到過這類場景,改了一個地方好幾個其他模塊也需要同步改動,模塊的邊界輕易被穿透,?
這種應用的架構有一個很形象的名字叫 “洋蔥架構”,洋蔥的特點就是一層又一層的粘連, 重構這樣的系統就像切洋蔥一樣讓人忍不住飆淚。

微服務架構強調 “微”,但如果采用了 SOA 服務化架構思想的系統會搞出很多胖服務來,一點也不微,這依然帶來耦合。?
這一點只能依賴系統架構師的服務化建模能力了,?
但微服務架構強調每個服務一個進程,?
使用進程為邊界來隔離代碼庫至少讓同一應用系統不同層次的開發人員享有自己完全自治的領地,?
每個微服務都有一個掌控者。

從某種程度上讓不小心做錯事,?
例如:跨出服務邊界的代碼耦合依賴,變得沒那么容易。

想象一個場景，一個 20 人的團隊維護一個 40 萬行共享代碼庫的單一應用,在里面修改 bug和添加功能都將十分困難。?
有一篇文章?《程序員的成長和代碼行數的關系》?里提到大部分普通程序員成長生涯的瓶頸在2萬行代碼左右,?
超過這個代碼行數的應用系統維護起來將倍感吃力,所以隨著咱們項目的逐漸發展膨脹,咱們團隊維護將會無比吃力。

通過分解巨大單體式應用為多個服務方法解決了復雜性問題?
在功能不變的情況下，應用被分解為多個可管理的分支或服務。?
每個服務都有一個用RPC-或者消息驅動API定義清楚的邊界?
微服務架構模式給采用單體式編碼方式很難實現的功能提供了模塊化的解決方案，由此，單個服務很容易開發、理解和維護。

專門團隊開發專門服務，技術選型靈活?
這種架構使得每個服務都可以有專門開發團隊來開發。?
開發者可以自由選擇開發技術，提供API服務。?
當然，許多公司試圖避免混亂，只提供某些技術選擇。?
然后，這種自由意味著開發者不需要被迫使用某項目開始時采用的過時技術，他們可以選擇現在的技術。?
甚至于，因為服務都是相對簡單，即使用現在技術重寫以前代碼也不是很困難的事情。

微服務架構模式是每個微服務獨立的部署?
開發者不再需要協調其它服務部署對本服務的影響。?
這種改變可以加快部署速度。?
UI團隊可以采用AB測試，快速的部署變化。?
微服務架構模式使得持續化部署成為可能。

微服務架構模式使得每個服務獨立擴展?
你可以根據每個服務的規模來部署滿足需求的規模。?
甚至于，你可以使用更適合于服務資源需求的硬件。?
比如，你可以在EC2 Compute Optimized instances上部署CPU敏感的服務，而在EC2 memory-optimized instances上部署內存數據庫。

縮短產品上市時間?
在整體化架構的應用中，任何微小的修改都需要重新部署整個應用棧，因此帶來了更高的風險和復雜度。?
這造成了更長的版本周期，因為修改可能會被累積，直到達到某個閾值時才發布新的版本。?
使用微服務，對于某個服務的修改可以被迅速的提交、測試和部署，因為對此服務的修改跟系統的其它部分是不相關的。

持續集成?
一種每天數次集成和測試開發人員的代碼改動的軟件開發實踐?
因為有更少的功能需要去測試而變得更簡單和快速。?
結果是版本的發布節奏更快，因為更少的代碼需要被編譯和重新測試。?
編排框架例如Kubernetes通過自動化上線、容器滾動更新和必要時的回滾進一步加快了產品上市的節奏。

靈活性和可擴展性?
單體架構的應用需要系統中的全部組件同時擴展。?
如果某個服務需要更高的性能，唯一的選項就是擴展系統中的所有服務而不是僅僅擴展需要擴容的單個服務。?
使用微服務，僅需要額外能力的單個服務需要擴容。?
擴容通過部署更多的容器來實現、可以實現更有效的容量計劃，更少的軟件授權和更低的總體擁有成本；?
因為服務和軟件可以更好的匹配。

彈性,容錯性?
整體架構應用的一個主要問題是當某個服務失效時可能整個系統可能都會受到連累。?
在微服務中，各個服務之間的隔離性使得單個服務的失效不會擴展到系統的其它部分進而造成全局性的影響。?
如果使用容器，編排框架可以提供額外的彈性：當某個容器失效時，一個新的容器會被啟動，進而實現完全的冗余和容量。

組織架構匹配?
微服務可以更好的匹配組織架構，因為團隊的規?？梢愿鶕枰瓿傻娜蝿者M行更好的定義。?
團隊可以被分成更小的小組并專注在應用的某個組件上。?
這對分布在不同地理位置的團隊來講是非常有用的。例如，在新加坡的團隊處理三個服務，在舊金山的團隊處理五個服務，這兩個團隊可以獨立的發布和部署功能組件。 這可以幫助處理相同組件的不同職能的團隊（Ops、Dev、QA）打破疆界和更好的合作。這也可以保證不同團隊之間的溝通跟不同的服務之間的API相匹配。本質上來講，服務之間的API定義了不同開發團隊之間應該相互提供的服務的契約。

降低成本?
通過使用容器，應用和環境（設計、測試、生產、支持）可以共享相同的基礎設施，?
結果是更高的硬件利用率和由于管理簡化帶來的成本降低。?
另外，微服務也會降低技術方面的開銷。?
在整體化架構的應用中，重構一個大型應用的代碼會帶來開銷（時間、資源）。?
通過將應用分解成可以通過API訪問的微服務，代碼重構可以逐個服務進行，結果是更少的時間去維護和更新代碼。

易于開發、理解?
由于每個服務只負責單一功能，開發者可以聚焦于自己負責的幾個服務模塊，對于其他服務，只需要理解接口即可。?
當然，單體應用經過良好設計也可以達到這個效果，?
但是，與單體應用的進程內通信或單機內的進程間通信不同的是，?
微服務的各服務之間一般采用RESTfulAPI或者異步消息隊列進行通信，無論 RESTful接口還是異步消息隊列都是開發語言無關的，極易理解的通信方式。

全局穩定性提高?
由于每個服務負責的功能單一，各服務的資源需求也相對更低。?
從而可以選擇將服務分散的部署到多臺中低配的服務器上，而不是一臺高配的機器上。?
如果某個機器上的服務故障，譬如說內存泄漏，故障只會影響該機器上的某一個或幾個服務，對全局影響不大。?
不受限于任何技術棧，極大的提高團隊搭建的速度。?
這一點對初創公司尤為重要，組建開發團隊對初創公司來說本來就是個頭疼的問題，如何還要求團隊的技術棧一致，招聘難度可想而知。但是，如果產品架構采用微服務架構，那么我們可以允許不同的服務模塊采用不同的技術棧，只需要定義好對外接口即可。局部的修改很容易部署，從而大大的提高了功能的交付效率。

如何確定軟件功能切分的粒度，邊界。?
太多的微服務模塊會導致服務間通信成本和運維成本的增加，過猶不及；?
但是若粒度過大，又違背了微服務的初衷。

多種技術棧（譬如 C，Java，Python，Scala 等）我們需要為每種語言準備編譯環境，運行環境等，增加了維護成本。

微服務模塊多了，會導致全局的上線次數變多，從而需要更復雜的版本管理和Bug跟蹤等，間接導致項目管理成本增加。

Fred Brooks在30年前寫道，“there are no silver bullets”，像任何其它科技一樣，微服務架構也有不足。?
其中一個跟他的名字類似，『微服務』強調了服務大小，實際上，有一些開發者鼓吹建立稍微大一些的，10-100 LOC服務組。?
盡管小服務更樂于被采用，但是不要忘了這只是終端的選擇而不是最終的目的。?
微服務的目的是有效的拆分應用，實現敏捷開發和部署。

微服務應用是分布式系統，由此會帶來固有的復雜性。開發者需要在RPC或者消息傳遞之間選擇并完成進程間通訊機制。?
更甚于，他們必須寫代碼來處理消息傳遞中速度過慢或者不可用等局部失效問題。?
當然這并不是什么難事，但相對于單體式應用中通過語言層級的方法或者進程調用，微服務下這種技術顯得更復雜一些。

分區的數據庫架構。?
商業交易中同時給多個業務分主體更新消息很普遍。這種交易對于單體式應用來說很容易，因為只有一個數據庫。?
在微服務架構應用中，需要更新不同服務所使用的不同的數據庫。使用分布式交易并不一定是好的選擇，不僅僅是因為CAP理論，還因為今天高擴展性的NoSQL數據庫和消息傳遞中間件并不支持這一需求。?
最終你不得不使用一個最終一致性的方法，從而對開發者提出了更高的要求和挑戰。

微服務架構模式應用的改變將會波及多個服務。?
比如，假設你在完成一個案例，需要修改服務A、B、C，而A依賴B，B依賴C。?
在單體式應用中，你只需要改變相關模塊，整合變化，部署就好了。?
對比之下，微服務架構模式就需要考慮相關改變對不同服務的影響。?
比如，你需要更新服務C，然后是B，最后才是A，幸運的是，許多改變一般只影響一個服務，而需要協調多服務的改變很少。

部署一個微服務應用也很復雜，一個分布式應用只需要簡單在復雜均衡器后面部署各自的服務器就好了。?
每個應用實例是需要配置諸如數據庫和消息中間件等基礎服務。?
相對比，一個微服務應用一般由大批服務構成。?
例如，根據Adrian Cockcroft，Hailo有160個不同服務構成，NetFlix有大約600個服務。?
每個服務都有多個實例。?
這就造成許多需要配置、部署、擴展和監控的部分，?
除此之外，你還需要完成一個服務發現機制，以用來發現與它通訊服務的地址（包括服務器地址和端口）。?
傳統的解決問題辦法不能用于解決這么復雜的問題。?
接續而來，成功部署一個微服務應用需要開發者有足夠的控制部署方法，并高度自動化。

架構師工作在抽象和具體兩個層面:?
架構是一項技術工作,技術工作要服務于組織的戰略目標。?
大量的工程實踐在每日的工作中不斷變化,而漸漸穩定的實踐方式被抽象提煉為一系列原則。?
原則的普及帶來整體效率的提升和邊際成本的下降,以更有效的支持組織戰略目標的快速達成。

跟蹤新技術發展確保能在合適的時候做出正確的取舍折衷。?
讓開發人員理解某項技術決策的影響和制約以便最有效的執行,甚至在特定情形下深入到代碼的實現層面。?
文章開頭說了,這是我們實施系統的第四個大版本,而之前每一個大版本升級都是一次舊城倒新城的整體搬遷。?
而微服務架構天然的自然進化屬性是否預示著這應該是最后一個大版本升級了??
微服務架構述說著沒有永恒的架構,只有進化的架構,但微服務架構不是銀彈,也沒有銀彈。

微服務架構深度依賴于容器化技術的使用。容器將微服務進程和應用程序隔離到更小的實例里，這些實例僅僅使用虛擬化了的操作系統，而不是整個虛擬機以及VM所包含的整個抽象硬件資源。

從微服務的運行載體來看，微服務架構的普及，依賴Docker等基于容器的技術在生產領域的大規模普及。微服務的思想，其實在之前的SOA的架構就萌發了，但是那事面向服務的思想，而少了一個“微”字。服務內部，依然是一個大雜燴。微服務，有點像原子，沒有辦法再進行切割。其核心的思想是每一個微服務的實體就是一個小的自治系統。這個實體不依賴其他的實體而獨立存在，運行。它能快速的創建，也能快速的銷毀。能夠相互組合，也能快速拆散。容器技術，為這種“原子”提供了一個很好的執行載體。而Docker技術，就是他們相互組合的粘合劑。但是，從目前的現狀來看，Docker在生產領域還尚未有大規模應用。這也是微服務技術無法大規模普及的原因之一。