文章鏈接：http://www.cnblogs.com/loveis715/p/4644266.html
將所有代碼和功能都包含在一個WAR包中的項目組織方式稱爲Monolith。
一個開發的服務，由多個項目組成，各個項目會根據自身所提供功能的不同具有一個明確的邊界，編譯時將這些代碼打包成一個個jar包，最終合在一起形成一個WAR包，將WAR包上傳到Web容器中，解壓WAR包，並重啓服務器。
以上這一系列操作完成之後，對服務的編譯及部署就完成了。
缺點：
（1）當項目較大時，僅僅更改一行代碼的情況下，需要花費幾十分鐘甚至更長時間對所有代碼進行編譯，花費大量時間重新部署剛生成的產品以驗證是否正確。
（2）按照該方式組織的代碼只生成一個包含所有功能的WAR包，在對服務的容量進行擴展時，只能重複地部署這些WAR包來擴展服務能力，而不是僅僅擴展出現系統瓶頸的組成。
（3）當一個服務中，某個組成的負荷達到90%，也就是必須爲其服務能力進行擴容的時候，而同一服務的其他三個組成負載還沒有達到其處理能力的20%。此時需要添加一個額外的服務實例講需要擴容的組成的負載降低到45%，也使得其他各組成的利用率更爲低下。
Microservice：
將整個WEB應用組織爲一系列小的Web服務，這些小的Web服務可以獨立的編譯及部署，並通過暴露的API藉口相互通訊，作爲一個整體爲用戶提供功能，卻可以獨立擴容。
例如，Wikipedia包含一系列的服務，如數據訪問Databases，搜索服務search等，這些服務包含數量不等的服務實例，以確保在不同負載情況下爲用戶提供服務，用戶請求到達時這些服務協同工作，一起完成對用戶請求的響應。
優點：
（1）通過編譯病重新部署單個子服務的方式驗證自己的更改，而不需要重新編譯整個應用，節省大量時間。
（2）每個子服務是獨立的，因此各個服務內部可以自行決定最合適的實現技術，使得開發更加容易
（3）如果當前系統的容量不夠用了，只需要找到系統瓶頸的子服務並擴展子服務的容量即可。
關於Microservice的經驗：
1、分割服務：
（1）傳統編寫服務活着桌面程序時首先嚐試將實現的功能分割爲一系列組件，並圍繞組件設計完成所需要的工作流及數據流，這將導致實現業務邏輯的組件都在同一個進程之內，實現也都在一個進程之內運行。
但是，
在MicroService架構中，在嘗試將需要實現的功能分割爲一系列組件之前，需要將實現的功能交由彼此相互獨立的一系列服務來完成。
（2）注意，
對於服務的分割和對於組件的分割是不同的，最重要的一點是在各個服務之間進行通訊的消耗相對於一個進程而言是非常大的，比進程內調用的時間長很多。
組件間的API要求具有細粒度，在當前進程中進行，速度非常快，因此頻繁調用沒有問題。
但是，在執行服務分割時定義的API需要粗粒度的API，以減少跨服調用的消耗。
（3）服務分割的粒度時服務分割過程中需要考慮的因素；如果一個服務的粒度太小，那麼它所提供的API的粒度也不會太高。
在MicroService架構中，一個服務需要能夠獨立完成特定的業務邏輯，至少是某個獨立資源的CRUD操作。
［CRUD：指在做計算處理時的增加（Create）、讀取查詢（Retrieve）、更新（Update）、刪除（Delete）幾個單詞的首字母簡寫。主要被用於描述軟件系統中數據庫活着持久層的基本操作功能］
（4）特殊情況：公共功能的處理。
問題：例如權限管理組件管理用戶所具有的各個權限，權限管理組件實現一種公用的安全模型，如ACL（Access Control List）、RBAC（Role－based Access Control）等。在每次訪問一個子服務時，這些服務都需要檢查用戶所具有的權限，這樣會使得系統的性能變的很差。
解決方法：將各個系統中下次還能夠使用的信息緩存起來，也就是在這些系統中爲用戶創建一個會話。
由於每個系統可能由多個服務實例所組成，爲了能夠重複利用會話中所儲存的信息，減少向公共服務發起請求的次數，需要通過負載平衡技術讓系統中的同一個服務實例處理同一個用戶的請求。如何實現該功能？http://www.cnblogs.com/loveis715/p/4547968.html
問題：公共服務會與各個服務產生一種邏輯上的依賴關係。
當權限管理的組成存在於多個服務之中的時候，可以直接通過傳入用戶的信息以及需要訪問的資源判斷出用戶是否能訪問特定資源，也就是說，從權限管理的組成所返回的實際上是一個布爾類型的數據。
但是管理權限時一個服務時，爲避免每次都調用權限管理服務，需要在用戶的會話中記錄用戶所具有的權限。在用戶下次訪問該服務時，可以直接檢查該用戶所具有的所有權限就能決定是否可以訪問特定資源。
在用戶會話中記錄的的權限常常具有某種特定的表現形式，如特定形式的字符串，而這種字符串需要同時被服務和權限管理服務所理解，從而造成兩個服務之間的耦合。
增大的耦合性會導致服務的重用性下降。
因此在分割過程中，服務的總體性能是至關重要的，而各個服務之間的獨立性也是關注的特性。
2、共享服務：
（1）在MicroService架構模型中，常需要一系列公有服務來輔助整個系統的運行。這些服務包括：權限管理服務，能夠監控各個服務實例的服務狀態，服務實例的添加刪除升級管理等等。
在剛開始使用Microsercive架構模式應用開發的時候，效率明顯低於通過Monolith進行開發的效率；但是隨着應用規模的增大，Microservice的開發效率明顯上升，而基於Monolith模式的效率逐步下降。
（2）Microservice在開發初期效率低下的原因：
公共服務需要在編寫第一個子服務的同時進行，這也是導致Microservice架構模式在開發初期效率低下的一個原因。
公共服務在保持和各個子服務的鬆耦合性的同時還需要提供一個足夠通用的、在一定程度上滿足當前和未來子服務要求的解決方案，這是另一個原因。
3、模型匹配：
在Microservice架構模型中，各個服務是彼此獨立的，而且是關注於自身業務邏輯的，因此在看待一個事物時，可能會有不同的視角，進而造成各個子服務中的對應模型並不匹配。
問題：當子服務的模型較少時，服務之間的依賴關係並沒有很多，那麼這種模型匹配還能夠解決，但是如果各個子服務之間的溝通很多，那麼各個子系統之間的模式匹配就會很複雜。
解決方法：使用公共服務對他們進行管理。在提供一個集中的公共服務的情況下，就不再需要處理這麼多的模型轉換了。
注意：對角色進行匹配並不合適，因爲對於不同的角色對同一個資源有着不同的操作權限。
在集中的公共服務中，需要使用較爲細粒度的模型，該模型具有較高的靈活性，以能夠無損的表示各個服務中的相應模型。
問題：Microservice架構模型簡化了單個子服務的實現，但是複雜了數據的處理，常見的麻煩有：保持多個子服務之間數據的一致性，粒度等。
解決方案：保持一致性的的工作通常是由事務來完成的，那麼Microservice中保持子服務之間數據一致性可以通過分佈式事務來實現。但是實現分佈式事務並不簡單，因此需要反思需要事務來保持數據一致性的子服務是否應該屬於同一個服務。另外關於粒度的問題，各個子服務之間所提供的API應該儘量的粗，但應儘量保持靈活性，最好的情況時通過一個服務間調用就獲得所有想要的信息。
Microservice實現：
1、問題：子服務之間哪裏可以出現耦合？出現什麼程度的耦合？
Ans：UI。運行在用戶瀏覽器中的UI需要與其他各個子服務進行交互，因此UI可以作爲中介者來完成各個子服務之間的交互。
因此在基於Microservice架構模式的服務中，常會出現一個前端服務。該服務所提供的頁面會與各個服務溝通，但它實際上不需要與其他服務之間進行通訊。
2、Ques：像上面這種情況，各個子服務就沒有UI了，而UI服務不僅僅處理所有的前端業務邏輯，而且如果需要介入第三方服務接入，打包在一起的UI服務將變成整個平臺的阻礙。
Ans：（1）在應用中嘗試借鑑Service Locator模式。此時需要的是一個UI框架，允許用戶通過特定方式在應用中插入各個子服務所提供的UI，並允許，並允許通過一些機制來發現已經在平臺中註冊的具有特定功能的API，並允許對該API進行調用。
（2）另一種模式是Message Broker，簡單的說就是一個消息的中轉平臺，允許其他組成向其中註冊消息，也允許其他組成組成偵聽消息。當一個組成將一個消息發送到了Message Broker之上後，其他偵聽該消息的各個組成則會根據消息中包含的信息更新自己的狀態。
3、Ques：如果服務需要支持移動設備，就不能讓這些移動設備一個一個訪問子服務了。因爲這些移動設備的帶寬一般都非常小，且用戶常處於信號不太好的地方，因此向這些子服務一個一個地發送請求將快速消耗掉他們所擁有的有限的帶寬。
Ans：通常在這些子服務之前搭建一個代理服務，代理服務將用戶請求根據業務邏輯拆分爲對各個子服務的請求，並將各個子服務所返回的結果歸納爲一個相應返回給用戶。
4、如何創建各個子服務所需要的公共服務？
對公共服務的調用是一個跨進度調用，因此相較於進程內調用效率低下，這種情況下需要儘量避免對該公共服務的重複調用，因此需要儘量使用戶訪問同一個子服務實例，並在該用戶的會話中緩存從公共服務中所得到的信息。
因此在同一個子服務的各個服務實例上，需要儘量使用負載平衡的Sticky Session的功能，並在一次公共服務調用中取得多項信息。
例如在查看用戶的權限時，不是查看用戶是否具有特定權限，而是用戶擁有哪些權限。
公共服務API的粒度需要粗一些，且同時具有一定的靈活性，從而通過減少服務間調用來避免整個服務的性能瓶頸。