引子：前幾天甲方博士問我,他用wpf弄個介面,能不能通過其他語言給他傳輸資料，我由此想到了webservice（此時此刻，我也沒有用過webService），作日翻閱了一些資料，對這塊技術有了個大概的瞭解。
看了webservice、就看到了soap協議、也看到了SOA思想，然後又引出微服務、微服務都引出來了，叢集與分散式兩兄弟都隨風而至。（說來慚愧，以上的技術以及思想，本人回顧之前的開發經歷，貌似都沒有實實在在的用過），不過沒有用過，我也想總結一下，混個臉熟，留個印象,貌似接下來要搞的專案這些都得用到。
先說說webService:
WebService是一種跨程式語言和跨作業系統平臺的遠端呼叫技術.
就好比你客戶端用c#開發了一套桌面介面，放在windows系統上執行，稱為A，我服務端用java寫了一個方法返回資料(xml、json),,我把java這個方法打包放到linux上，成為B。然後A從B獲取資料，A B一起幹活，不亦樂乎！網路上比較典型的例證就是。在騰訊qq介面上的天氣預告就是呼叫氣象局的webservice，獲取資料，然後展示在自己的介面上(我也在想，之前做的專案前後端不分離，但是我前端也是通過ajax呼叫後端controller的方法，獲取到想要的json,這跟webservice多少有些像吧，只是沒有像webservice分的這麼明顯，看官大神請指正，嘿嘿)
webService三要素
叢集是個物理形態，分散式是個工作方式。
1.分散式：一個業務分拆多個子業務，部署在不同的伺服器上
2.叢集：同一個業務，部署在多個伺服器上
分散式是指將不同的業務分佈在不同的地方。而叢集指的是將幾臺伺服器集中在一起，實現同一業務。
分散式中的每一個節點，都可以做叢集。而叢集並不一定就是分散式的。
舉例：就比如新浪網，訪問的人多了，他可以做一個叢集，前面放一個響應伺服器，後面幾臺伺服器完成同一業務，如果有業務訪問的時候，響應伺服器看哪臺伺服器的負載不是很重，就將給哪一臺去完成。
而分散式，從窄意上理解，也跟叢集差不多，但是它的組織比較鬆散，不像叢集，有一個組織性，一臺伺服器垮了，其它的伺服器可以頂上來。
分散式的每一個節點，都完成不同的業務，一個節點垮了，那這個業務就不可訪問了。
簡單說，分散式是以縮短單個任務的執行時間來提升效率的，而叢集則是通過提高單位時間內執行的任務數來提升效率。
微服務
1. 微服務的誕生
微服務是基於分而治之的思想演化出來的。過去傳統的一個大型而又全面的系統，隨著網際網路的發展已經很難滿足市場對技術的需求，於是我們從單獨架構發展到分散式架構，又從分散式架構發展到 SOA 架構，服務不斷的被拆分和分解，粒度也越來越小，直到微服務架構的誕生。
微服務架構是一種架構模式，它提倡將單一應用程式劃分成一組小的服務，服務之間互相協調、互相配合，為使用者提供最終價值。
每個服務執行在其獨立的程式中，服務和服務間採用輕量級的通訊機制互相溝通（通常是基於 HTTP 的 RESTful API）。每個服務都圍繞著具體業務進行構建，並且能夠被獨立地部署到生產環境、類生產環境等。另外，應儘量避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建。
2. 微服務架構與SOA架構的區別
微服務是真正的分散式的、去中心化的。把所有的“思考”邏輯包括路由、訊息解析等放在服務內部，去掉一個大一統的 ESB，服務間輕通訊，是比 SOA 更徹底的拆分。
微服務架構強調的重點是業務系統需要徹底的元件化和服務化，原有的單個業務系統會拆分為多個可以獨立開發，設計，執行和運維的小應用，這些小應用之間通過服務完成互動和整合。
總結一下，其實我自己感覺 分散式、SOA、微服務 三者的思想是一致的，都是將一個系統分而治之，互相解耦，只是三者的分治力度大小不一樣，分散式<SOA<微服務(個人見解啊，若有不當，望大家糾正)
說在最後：其實不管啥技術，基本都是業務催生的，要做好一個專案其實並不是你用的技術多牛就行，而是你要把這個專案做的讓客戶滿意才行。另外我們在工作中、生活中、不斷得提高自己，望每個程式設計師都有一個好的環境提高自己，賺足錢，娶老婆！另外發個牢騷：今年上班兩個多月了，才領了一個多月工資，然而租房也兩個多月了，卻要交半年的房租，不容易啊！，加油。