Spring Cloud與微服務構建：微服務簡介

Spring Cloud與微服務構建：微服務簡介

單體架構及其不足

1.單體架構簡介
在軟件設計中，常常說起和使用經典的3曾模型，即表示層、業務邏輯層和數據訪問層。

• 表示層：用於直接和用戶交互，也成爲交互曾，一般是網頁、UI等；
• 業務邏輯層：即業務邏輯處理層，例如用戶輸入的信息要通過業務邏輯層的處理後，才能展示給用戶；
• 數據訪問層：用於操做數據庫，用戶在表示層會產生大量的數據，經過數據訪問層對數據庫進行讀寫操做；

雖然在軟件設計中劃分了經典的3層模型，可是對業務場景沒有劃分。一個典型的單體應用就是將全部的業務場景的表示層、業務邏輯層和數據訪問層放在一個工程中，最終經過編譯、打包，部署在一臺服務器上。例如典型的J2EE工程，它是將表示層的JSP、業務邏輯層的Service、Controller和數據訪問層的Dao打成war包，部署在Tomcat、Jetty或者其餘Servlet容器中運行。經典的單體應用以下圖所示：

在一個小型應用的初始階段，訪問量較小，應用只須要一臺服務器就可以部署全部的資源，例如將應用程序、數據庫、文件資源等部署在同一臺服務器上。最典型的就是LAMP系統，即服務器採用Linux系統，開發應用程序的語言爲PHP，部署在Apache服務器上，採用MySQL數據庫。在應用程序的初始階段，採用這種架構的性價比是很是高的，開發速度快，開發成本低，只須要一臺廉價的服務器。此時的服務器架構以下圖所示：

2.單體架構存在的不足
在應用的初始階段，單體架構不管是在開發速度、運維難度上，仍是服務器的成本上都有着顯著的優點。在一個產品的前景不明確的初始階段，用單體架構是很是明智的選擇。隨着應用業務的發展和業務複雜度的提升，這種架構明顯存在不少的不足，主要體如今如下3個方面：

• 業務愈來愈複雜，單體應用的代碼量愈來愈大，代碼的可讀性、可維護性和可擴展性降低，新人接手代碼所需時間成倍增長，業務擴展帶來的代價愈來愈大；
• 隨着用戶愈來愈多，程序承受的併發愈來愈高，單體應用的併發能力有限；
• 測試的難度愈來愈大，單體應用的業務都在同一個程序中，隨着業務的擴張、複雜度的增長，單體應用修改業務或者增長業務或許會給其餘業務帶來必定的影響，致使測試難度增長；

3.單體架構使用服務器集羣及存在的不足
隨着業務的發展，大多數公司會將單體應用進行集羣部署，並增長負載均衡服務器(例如Nginx等)。另外，還須要增長集羣部署的緩存服務器和文件服務器，並將數據庫讀寫分離，以應對用戶量的增長而帶來的高併發訪問量。此時的系統架構以下如所示：

用負責均衡服務器分發高併發的網絡請求，用戶的訪問被分派到不一樣的應用服務器，應用服務器的負載再也不成爲瓶頸，用戶量增長時，添加應用服務器便可。經過添加緩存服務器來緩解數據庫的數據以及數據庫讀取數據的壓力。大多數的讀取操做是由緩存完成的，可是仍然有少數操做是從數據庫讀取的，例如緩存失效、實時數據等。當有大量的讀寫操做時，將數據庫進行讀寫分離是一個不錯的選擇，例如MySQL的主從熱備份，經過相關配置能夠將主數據流服務器的數據同步到從數據庫服務器，實現數據庫的讀寫分離，讀寫分離可以改善數據庫的負載能力。
這種架構有必定的處理高併發的能力，也能應對必定複雜的業務需求，改善了系統的性能。可是依然沒有改變系統爲單體架構的事實，此時系統存在的不足之處以下：

• 系統仍然爲單體應用，大量的業務必然會有大量的代碼，代碼的可讀性和可維護性依然不好；
• 面對海量的用戶，數據庫將會成爲瓶頸，解決方案將使用分佈式數據庫，也就是將數據庫進行分庫分表；
• 持續交付能力差，業務越複雜代碼越多，修改代碼和添加代碼所需時間越長，新人熟悉代碼的時間長、成本高；

因而可知，在應用初期，單體應用從成本、開發時間和運維等方面都有明顯的優點。可是隨着業務量和用戶量的增長，它所暴露出來的缺點也顯而易見。單體架構已經不能知足複雜的業務和海量的用戶系統，改變單體架構勢在必行。

微服務

一.什麼是微服務
"微服務"最初是由Martin Fowler在2014年寫的一篇文章《MicroServices》中提出來的。關於Martin Fowler的介紹，維基百科上是這樣描述的：

Martin Fowler，軟件工程師，也是一個軟件開發方面的著做者和國際知名演說家，專一於面向對象分析>與設計、統一建模語言、領域建模，以及敏捷軟件開發方法，包括極限編程。主要著做有《可重用對象>模型》《重構-改善既有代碼的設計》《企業應用架構模式》等；

對於微服務，業界沒有一個嚴格統一的定義，可是做爲"微服務"這一名詞的發明人，Martin Fowler對於微服務的定義彷佛更具備權威性和指導意義。他的理解以下：

簡而言之，微服務架構的風格，就是將單一程序開發成一個微服務，每一個微服務運行在本身的進程>中，並使用輕量級機制通訊，一般是HTTP RESTFUL API。這些服務圍繞業務能力來劃分構建的，>並經過徹底自動化部署機制來獨立部署。這些服務可使用不一樣的編程語言，以及不一樣數據存儲技>術，以保證最低限度的集中式管理；

以我我的對這段話的理解，總計微服務具備以下特色：

• 按業務劃分爲一個獨立運行的程序，即服務單元；
• 服務之間經過HTTP協議相互通訊；
• 自動化部署；
• 能夠用不一樣的編程語言；
• 能夠用不一樣的存儲技術；
• 服務集中化管理；
• 微服務是一個分佈式系統；

1.微服務單元按業務來劃分
微服務的"微"到底須要定義到什麼樣的程度，這是一個很是難以界定的概念，能夠從如下3個方面來界定：一是根據代碼量來定義，根據代碼的多少來判斷程序的大小；二是根據開發時間的長短來判斷；三是根據業務的大小來劃分。
根據Martin Fowler的定義，微服務的"微"是按照業務來劃分的。一個大的業務能夠拆分紅若干小的業務，一個小的業務又能夠拆分紅若干更小的業務，業務到底怎麼拆分纔算合適，這須要開發人員本身去決定。例如微博最多見的功能是微博內容、關注和粉絲，而其中微博內容又有點贊、評論等，如何將微博這個複雜的程序劃分爲單個的服務，須要開發團隊去決定。
按業務劃分的微服務單元獨立不是，運行在獨立的進程中。這些微服務單元是高度組件化的模塊，並提供了穩定的模塊邊界，服務與服務之間沒有任何的耦合，有很是好的擴展性和複用性。
傳統的軟件開發模式一般由UI團隊、服務端團隊、數據庫和運維團隊構成，相應地將軟件按照職能劃分爲UI、服務端、數據庫和運維等模塊。一般這些開發人員各司其職，不多有人跨職能去工做。若是按照業務來劃分服務，每一個服務都須要獨立的UI、服務端、數據庫和運維。也就是說，一個小的業務的微服務須要動用一個團隊的人去協做，這顯然增長了團隊與團隊之間交流協做的成本。因此產生了跨職能團隊，這個團隊負責一個服務的全部工做，包括UI、服務端和數據庫。當這個團隊只有1-2我的的時候，就對開發人員提出了更高的要求。

2.微服務經過HTTP來互相通訊
按照業務劃分的微服務單元獨立部署，並運行在各自的進程中。微服務單元之間的通訊方式通常傾向於使用HTTP這種簡單的通訊機制，更多的時候是使用RESTFUL API。這種接受請求、處理業務邏輯、返回數據的HTTP模式很是高效，而且這種通訊機制與平臺和語言無關。例如用Java寫的服務能夠消費用Go語言寫的服務，用Go語言寫的服務又能夠小費用Ruby寫的服務。不一樣的服務採用不一樣的語言去實現，不一樣的平臺去部署，它們之間使用HTTP進行通訊，以下圖所示：

服務與服務之間也能夠經過輕量級的消息總線來通訊，例如RabbitMQ、Kafaka等。經過發送消息或者訂閱消息來達到服務與服務之間通訊的目的。
服務與服務通訊的數據格式通常爲JSON、XML，這兩種數據格式與語言、平臺、通訊協議無關。通常來講，JSON格式的數據比XML輕量，而且可讀性也比XML要好。另一種就是用Protobuf進行數據序列化，通過序列化的數據爲二進制數據，它比JSON更輕量。用Protobuf序列化的數據爲二進制數據，可讀性很是差，須要反序列化才能讀懂。因爲用Protobuf序列化的數據更爲輕量，因此Protobuf在通訊協議和數據存儲上十分受歡迎。
服務與服務之間經過HTTP或消息總線的方式進行通訊，這種方式存在弊端，其通訊機制是不可靠的，雖然成功率很高，可是仍是會有失敗的時候。

3.微服務的數據庫獨立
在單體架構中，全部的業務都共用一個數據庫。隨着業務量的增長，數據庫表的數量愈來愈多，難以管理和維護，而且數據量的增長會致使查詢速度愈來愈慢。例如一個應用有這樣幾個業務：用戶信息、用戶帳戶、用戶購物車、數據報表服務等。典型的單體架構以下圖所示：

微服務的一個特色就是按照業務劃分服務，服務與服務之間無耦合，就連數據庫也是獨立的。一個典型的微服務的架構就是每一個微服務都有本身獨立的數據庫，數據庫之間沒有任何聯繫。這樣作的好處在於，隨着業務的無論擴張，服務與服務不須要提供數據庫集成，而是提供API接口相互調用；還有一個好處是數據庫獨立，單業務的數據量少，易於維護，數據庫性能有着明顯的優點，數據庫的遷移也很方便。
另外，隨着存儲技術的發展，數據庫的存儲方式數據庫的存儲方式再也不僅僅是關係型數據庫，非關係型數據庫的應用也很是普遍。例如Redis、MongoDB，它們有着良好的讀寫性能，所以愈來愈受歡迎。一個典型的微服務系統，可能每個服務的數據庫都不相同，每一個服務所使用的數據存儲技術須要根據業務需求來選擇，以下圖所示：

4.微服務的自動化部署
在微服務架構中，系統會被拆分爲若干個微服務，每一個微服務又是一個獨立的應用程序。單體架構的應用程序只須要部署一次，而微服務架構有多少個服務就須要部署多少次。隨着服務數量的增長，若是微服務按照單體架構的部署方式，部署的難度會呈指數增長。業務的粒度劃分的越細，微服務的數量就越多，這時須要更穩定的部署機制。隨着技術的發展，尤爲是Docker容器技術的推動，以及自動化部署工具(開源組件Jenkins)的出現，自動化部署變得愈來愈簡單。
自動化部署能夠提升部署的效率，減小人爲的控制，部署過程當中出現錯誤的機率下降，部署過程的每一步自動化，提升軟件的質量。構建一個自動化部署的系統，雖然在前期須要開發人員或運維人員的學習，可是對於整個軟件系統來講是一個全系的概念。在軟件系統的整個生命週期中，每一步是由程序控制的，而不是人爲控制，軟件的質量提升到了一個新的高度。隨着DevOps這種全新概念的推動，自動化部署必然會成爲微服務部署的一種方式。

5.服務集中化管理
微服務系統是按業務單元來劃分服務的，服務數量越多，管理起來就越複雜，所以微服務必須使用集中化管理。目前流行的微服務框架中，例如Spring Cloud採用Eureka來註冊服務和發現，另外Zookeeper、Consul等都是優秀的服務集中化管理框架。

6.分佈式架構
分佈式系統是集羣部署的，由不少計算機相互協做共同構成，它可以處理海量的用戶請求。當分佈式系統對外提供服務時，用戶是絕不知情的，還覺得是一臺服務器在提供服務。分佈式系統的複雜任務經過計算機之間的相互協做來完成，固然簡單的任務也能夠在一臺計算機上完成。
分佈式系統經過網絡協議來通訊，因此分佈式系統在空間上沒有任何限制，即分佈式服務器能夠部署不一樣的機房和不一樣的地區。
微服務架構是分佈式架構，分佈式系統比單體系統更加複雜，主要體如今服務的獨立性和服務相互調用的可靠性，以及分佈式事務、全局鎖、全局ID等，而單體系統不須要考慮這些複雜性。
另外，分佈式系統的應用都是集羣化部署，會給數據一致性帶來困難。分佈式系統中的服務通訊依賴於網絡，網絡很差，必然會對分佈式系統帶來很大的影響。在分佈式系統中，服務之間相互依賴，若是一個服務出現了故障或網絡延遲，在高併發的狀況下，會致使線程阻塞，在很短的時間內該服務的線程資源會消耗殆盡，最終使得該服務不可用。因爲服務的相互依賴，可能會致使整個系統的不可用，這就是"雪崩效應"。爲了防止此類事件的發生，分佈式系統必然要採起相應的措施，例如"熔斷機制"。

7.熔斷機制
爲了防止"雪崩效應"事件的發生，發呢不是系統採用了熔斷機制。在用Spring Cloud構建的微服務系統中，採用了熔斷器(即Hytrix組建的Circuit Breaker)去作熔斷。
例如在微服務系統中，有a、b、c、d、e、f、g、h等多個服務，用戶的請求經過網關後再到具體的服務，服務之間相互依賴，例如服務b依賴於服務f，一個對外暴露的API接口須要服務b和服務f相互協做才能完成。服務之間相互以來的架構以下圖所示：

若是此時服務b出現故障或網絡延遲，在高併發的狀況下，服務b會出現大量的線程阻塞，有可能在很短的時間內線程資源就被消耗完了，致使服務b的不可用。若是服務b爲較底層的服務，會影響到其餘服務，致使其餘服務會一直等待服務b的處理。若是服務b遲遲不處理，大量的網絡請求不只僅堆積在服務b，並且會堆積到依賴於服務b的其餘服務。於是服務b出現故障影響的服務，也會影響到依賴於服務b出現故障影響的服務的其餘服務，從而由b開始，影響到整個系統，致使整個系統的不可用。這是一件很是可怕的事，由於服務器運營商的不可靠，必然會致使服務的不可靠，而網絡服務商的不可靠，也會致使服務的不可靠。在高併發的場景下，稍微有點不可靠，因爲故障的傳播性，會致使大量的服務不可用，甚至致使整個系統崩潰。
爲了解決這一難題，微服務架構引入了熔斷機制。當服務b出現故障，請求失敗次數超過設定的閾值以後，服務b就會開啓熔斷器，以後服務b不進行任何的業務邏輯操做，執行快速失敗，直接返回請求失敗的信息。其餘依賴於b的服務就不會由於得不到響應而線程阻塞，這時除了服務b和依賴於服務b的部分功能不可用外，其餘功能正常。熔斷服務以下圖所示：

熔斷器還有另一個機制，即自我修復的機制。當服務b熔斷後，通過一段時間，半打開熔斷器。半打開的熔斷器會檢查一部分請求是否正常，其餘請求執行快速失敗，檢查的請求若是響應成功，則能夠斷定服務b正常了，就會關閉服務b的熔斷器；若是服務b還不正常，則繼續打開熔斷器。這種自我熔斷機制和自我修復機制在微服務架構中有着重要的意義，一方面它使程序更加健壯，另外一方面爲開發和運維減小不少沒必要要的工做。
最後熔斷組件每每會提供一系列的監控，例如服務可用與否、熔斷器是否打開、目前的吞吐量、網絡延遲狀態的監控等，從而很容易讓開發人員和運維人員實時瞭解服務的狀態。

二.微服務的優點
相對於單體服務來講，微服務具備不少優點，主要體如今如下方面：
1)將一個複雜的業務分解成若干小的業務，每一個業務拆分紅一個服務，服務的邊界明確，將複雜的問題簡單化。服務按照業務拆分，編碼也是按照業務來拆分，代碼的可讀性和可擴展性增長。新人加入團隊，不須要了解全部的業務代碼，只須要了解他所接管的服務的代碼，新人學習時間成本減小。
2)因爲微服務系統是分佈式系統，服務與服務之間沒有任何的耦合。隨着業務的增長，能夠根據業務再拆分服務，具備極強的橫向擴展能力。隨着應用的用戶量的增長，併發量增長，能夠將微服務集羣化部署，從而增長系統的負載能力。簡而言之，微服務系統的微服務單元具備很強的橫向擴展能力。
3)服務與服務之間經過HTTP網絡通訊協議來通訊，單個微服務內部高度耦合，服務與服務之間徹底獨立，無耦合。這使得微服務能夠採用任何開發語言和技術來實現。開發人員再也不被強迫使用公司之前的技術或已通過時的技術，而是能夠自由選擇最合適業務場景的或適合本身的開發語言和技術，提供開發效率、減低開發成本。
4)若是是一個單體的應用，因爲業務的複雜性、代碼的耦合性，以及可能存在的歷史問題。在重寫一個單體應用時，要求重寫應用的人員瞭解全部的業務，因此重寫單體應用是很是困難的，而且重寫風險也很高。若是是微服務系統，因爲爲服務是按照業務的進行拆分的，而且有堅實的服務邊界，因此重寫某個服務就至關於重寫某一個業務的代碼，很是簡單。
5)微服務的每一個服務單元都是獨立部署的，即獨立運行在某個進程裏。微服務的修改和部署對其它服務沒有影響。試想，假設一個應用只有一個簡單的修改，若是是單體架構，須要測試和部署整個應用；而若是採用微服務架構，只須要測試並部署被修改的那個服務，這就大大減小了測試和部署的時間。
6)微服務在CAP理論中採用的是AP架構，即具備高可用和分區容錯的特色。高可用主要體如今系統7*24小時不間斷的服務，它要求系統有大量的服務器集羣，從而提升了系統的負載能力。另外，分區容錯也使得系統更加健壯。

三.微服務的不足
凡事都有兩面性，微服務也不例外，微服務相對於單體應用來講具備不少的優點，固然也有其不足之處，主要體如今以下方面：
1.微服務的複雜度
構建一個微服務系統並非一件容易的事，微服務系統是分佈式系統，構建的複雜度遠遠超過單體系統，開發人員須要付出必定的學習成本去掌握跟過的架構知識和框架知識。服務於服務之間經過HTTP協議或消息傳遞機制通訊，開發者須要選出最佳的通訊機制，並解決網絡服務較差時帶來的風險。
另外服務與服務之間相互依賴，若是修改某一個服務，會對另一個服務產生影響，若是掌控很差，會產生沒必要要的麻煩。因爲服務的依賴性，測試也會變得複雜，好比修改一個比較基礎的服務，可能須要重啓全部的服務才能完成測試。

2.分佈式事務
微服務架構所設計的系統是分佈式系統。分佈式系統有一個著名的CAP理論，即同時知足"一致性"、"可用性"和"分區容錯"是一件不可能的事。CAP理論是有Eric Brewer在2000年PODC會議上提出的，該理論在兩年後被證實成類。CAP理論告訴架構師不要妄想設計出同時知足三者的系統，應該有所取捨，設計出適合業務的系統。CAP理論以下如所示：

• Consistency：指數據的強一致性，若是寫入某個數據成功，以後讀取，讀到的都是新寫入的數據；若是寫入失敗，以後讀取的都不是寫入失敗的數據；
• Aavilability：指服務的可用性；
• Partition-tolerrance：指分區容錯；

在分佈式系統中，P是基本要求，而單體服務是CA系統。微服務系統一般是一個AP系統，即同時知足可用性和分區容錯。這就有了一個難題：在分佈式系統中如何確保數據的一致性？這就是你們常常討論的分佈式事務。
在微服務系統中，每一個服務都是獨立的進程單元，每一個服務都有本身的數據庫。一般狀況下，只有關係型數據庫在特定的數據引擎下才支持事務，而大多數非關係型數據庫是不支持事務的，例如MongoDB是不支持事物的，而Redis是支持事務的。在微服務架構中，分佈式事務一直都是一個難以解決的問題，業界給出的解決方案一般是兩階段提交。
網上購物在平常生活中是一個很是普通的場景，假設咱們在淘寶上買了一部手機，須要從個人帳戶中扣除1000元錢，同時手機的庫存數量須要減1.固然須要在賣方的帳戶中加1000元錢，爲了使案例簡單化，暫時不用考慮其餘。
若是這是一個單體應用，而且使用支持事物的MySQL數據庫(InnoDB數據庫引擎才支持事務)，咱們能夠這樣寫代碼：

@Transacntional
public void update() throws RuntimeException{
    updateAccountTable();        // 更新帳戶表
    updateGoodsTable();        // 更新商品表
}

若是是微服務架構，帳戶是一個服務，而商品是一個服務，這時不能用數據庫自帶的事務，由於這兩個數據表不在一個數據庫中。所以經常用到兩個階段提交，兩個階段提交的過程以下如所示：

第一階段，service-account發起一個分佈式事務，交給事務協調器TC處理，事務協調器TC向全部參與的事務的節點發送處理事務操做的準備操做。全部的參與節點執行準備操做，將Undo和Redo信息寫入日誌，並向事務管理器返回準備操做是否成功；
第二階段，事務管理器收集全部節點的準備操做是否成功，若是都成功，則通知全部的節點執行提交操做；若是有一個失敗，則執行回滾操做；
兩階段提交，將事務分紅兩部分可以大大提升分佈式事務成功的機率。若是在第一階段都成功了，而執行第二階段的某一個節點失敗，仍然致使數據的不許確，這時通常須要人工去處理，這就是當初在第一步記錄日誌的緣由。另外，若是分佈式事務涉及的節點不少，某一個節點的網絡出現異常會致使整個事務處於阻塞狀態，大大下降數據庫的性能。因此通常狀況下，儘可能少用分佈式事務。

3.服務的劃分
將一個完整的系統拆分紅不少個服務，是一件很是困難的事，由於這涉及到了具體的業務長江，比明明一個類更加困難。對於微服務的拆分原則，Martin Fowler給出的建議是：服務是能夠被替換和更新的。也就是服務和服務之間無耦合，任何一個服務均可以被替換，服務有本身嚴格的邊界。固然這個原則很抽象，根據具體的業務場景來拆分服務，須要依靠團隊人員對業務的熟悉程度和理解程度，並考慮與已有架構的衝入、業務的擴展性、開發的風險和將來業務的發展等諸多因素。
領域驅動設計是一個全新的概念，也是一個比較理想的微服務拆分的理念。領域驅動設計經過代碼和數據分析找到合理的切分點，並經過數據分析來判斷服務的劃分邊界和劃分粒度。目前來講，在中國幾乎沒有公司去落地領域驅動設計這個理念，隨着微服務的發展，這一理念在之後有可能會落地。

4.服務的部署
一個簡單的單體系統可能只須要將程序集羣部署並配置負載均衡服務器便可，而部署一個複雜的微服務架構的系統就複雜得多。由於每個微服務可能還涉及比較低層的組件，例如數據庫、消息中間件等。微服務系統每每由數量衆多的服務構成，例如Netflix公司大約有600個服務，而每一個服務又有大量的實例。微服務系統須要對每一個服務進行治理、監控和管理等，而每一個服務有大量的配置，還須要考慮服務的啓動順序和啓動時機等。
部署微服務系統，須要開發人員或者運維人員對微服務系統有足夠強的控制力。隨着雲計算和雲服務器的發展，部署微服務系統並非一件難事，例如使用PaaS服務、使用Docker編排等。這就是人們每每提到微服務，就會想到Docker、DevOps的緣由。其中，微服務是核心；Docker爲容器技術，是微服務最佳部署的容器；DevOps是一種部署手段或理念，他們的關係如圖所示：

四.微服務和SOA的關係
SOA即面向服務的架構，這種架構在20年前就已經被提出了。SOA每每與企業服務總線(ESB)聯繫在一塊兒，主要緣由在於SOA的實施思路是根據ESB模式來整合集成大量單一龐大的系統，這是SOA主要的落地方式。然而，SOA在過去20年並無取得成功。在談到微服務時，人們很容易聯想到它是一個面向服務的架構，的確，微服務的概念提出者Martin Fowler並無否定這一層關係。
微服務相對於和ESB聯繫在一塊兒的SOA顯然輕便敏捷得多，微服務將複雜的業務組件化，實際也是一種面向服務思想的體現。對於微服務來講，它是SOA的一種實現，可是它比ESB實現的SOA更加輕便、敏捷和簡單。

五.微服務的設計原則 軟件設計就比如建築設計。Architect這個詞在建築學中是"建築師"的意思，而在軟件領域則是"架構師"的意思，可見它們確實有類似之處。不管是建築師仍是架構師，他們都但願把做品設計出本身的特點，而且更願意把創造出來的東西稱之爲藝術品。然而現實倒是，建築設計和軟件設計有很是大的區別。建築師設計並建造出來的建築每每很難有變化，除非拆了重建。而架構師設計出來的軟件系統，爲了知足產品的業務發展，在它的整個生命週期中，每個版本都有不少的變化。 軟件設計每個版本都在變化，因此軟件設計應該是漸進式發展。軟件從一開始就不該該被設計成微服務架構，微服務架構當然有優點，可是它須要更多的資源，包括服務器資源、技術人員等。追去大公司所帶來的技術解決方案，刻意地追求某個新技術，企圖使用新技術解決全部的問題，這些都是軟件設計的誤區。 技術應該是隨着業務的發展而發展的，任何脫離業務的技術是不能產生價值的。在初創公司，業務很單一時，若是在LAMP單體架構夠用的狀況下，就應該用LAMP，由於它開發速度快，性價比高。隨着業務的發展，用戶量的增長，能夠考慮將數據庫讀寫分離、加緩存、加負載均衡器、將應用程序集羣化部署等。若是業務還在不斷髮展，這時能夠考慮使用分佈式系統，例如微服務架構的系統。無論使用什麼樣的架構，驅動架構發展的必定是業務的發展，只有當前架構不適合當前業務的發展，才考慮更換架構。 在微服務架構中，有三大難題，那就是服務故障的傳播性、服務的劃分和分佈式事務。在微服務設計時，必定要考慮清楚這三個難題，從而選擇合適的框架。目前比較流行的微服務框架有Spring社區的Spring Cloud、Google公司的Kubernetes等。無論使用哪種框架或者工具，都須要考慮這三大難題。爲了解決服務故障的傳播性，通常的微服務框架都有熔斷機制組件。另外，服務的劃分沒有具體的劃分方法，通常來講根據業務來劃分服務，領域驅動設計具備指導做用。最後，分佈式事務通常的解決辦法就是兩階段提交或者三階段提交，無論使用哪種都存在事務失敗，致使數據不一致的狀況，關鍵時刻還得人工去恢復數據。總之，微服務的設計必定是漸進式的，而且是隨着業務的發展而發展的。