什么是微服務
在介紹微服務時，首先得先理解什么是微服務，顧名思義，微服務得從兩個方面去理解，什么是"微"、什么是"服務"， 微 狹義來講就是體積小、著名的"2 pizza 團隊"很好的詮釋了這一解釋（2 pizza 團隊最早是亞馬遜 CEO Bezos提出來的，意思是說單個服務的設計，所有參與人從設計、開發、測試、運維所有人加起來 只需要2個披薩就夠了 ）。 而所謂服務，一定要區別于系統，服務一個或者一組相對較小且獨立的功能單元，是用戶可以感知最小功能集。
微服務由來
微服務最早由Martin Fowler與James Lewis于2014年共同提出，微服務架構風格是一種使用一套小服務來開發單個應用的方式途徑，每個服務運行在自己的進程中，并使用輕量級機制通信，通常是HTTP API，這些服務基于業務能力構建，并能夠通過自動化部署機制來獨立部署，這些服務使用不同的編程語言實現，以及不同數據存儲技術，并保持最低限度的集中式管理。
為什么需要微服務？
在傳統的IT行業軟件大多都是各種獨立系統的堆砌，這些系統的問題總結來說就是擴展性差，可靠性不高，維護成本高。到后面引入了SOA服務化，但是，由于 SOA 早期均使用了總線模式，這種總線模式是與某種技術棧強綁定的，比如：J2EE。這導致很多企業的遺留系統很難對接，切換時間太長，成本太高，新系統穩定性的收斂也需要一些時間。最終 SOA 看起來很美，但卻成為了企業級奢侈品，中小公司都望而生畏。
單體架構問題
單體架構在規模比較小的情況下工作情況良好，但是隨著系統規模的擴大，它暴露出來的問題也越來越多，主要有以下幾點：
1.復雜性逐漸變高
比如有的項目有幾十萬行代碼，各個模塊之間區別比較模糊，邏輯比較混亂，代碼越多復雜性越高，越難解決遇到的問題。
2.技術債務逐漸上升
公司的人員流動是再正常不過的事情，有的員工在離職之前，疏于代碼質量的自我管束，導致留下來很多坑，由于單體項目代碼量龐大的驚人，留下的坑很難被發覺，這就給新來的員工帶來很大的煩惱，人員流動越大所留下的坑越多，也就是所謂的技術債務越來越多。
3.部署速度逐漸變慢
這個就很好理解了，單體架構模塊非常多，代碼量非常龐大，導致部署項目所花費的時間越來越多，曾經有的項目啟動就要一二十分鐘，這是多么恐怖的事情啊，啟動幾次項目一天的時間就過去了，留給開發者開發的時間就非常少了。
4.阻礙技術創新
比如以前的某個項目使用struts2寫的，由于各個模塊之間有著千絲萬縷的聯系，代碼量大，邏輯不夠清楚，如果現在想用spring mvc來重構這個項目將是非常困難的，付出的成本將非常大，所以更多的時候公司不得不硬著頭皮繼續使用老的struts架構，這就阻礙了技術的創新。
5.無法按需伸縮
比如說電影模塊是CPU密集型的模塊，而訂單模塊是IO密集型的模塊，假如我們要提升訂單模塊的性能，比如加大內存、增加硬盤，但是由于所有的模塊都在一個架構下，因此我們在擴展訂單模塊的性能時不得不考慮其它模塊的因素，因為我們不能因為擴展某個模塊的性能而損害其它模塊的性能，從而無法按需進行伸縮。
微服務與單體架構區別
單體架構所有的模塊全都耦合在一塊，代碼量大，維護困難，微服務每個模塊就相當于一個單獨的項目，代碼量明顯減少，遇到問題也相對來說比較好解決。
單體架構所有的模塊都共用一個數據庫，存儲方式比較單一，微服務每個模塊都可以使用不同的存儲方式（比如有的用redis，有的用mysql等），數據庫也是單個模塊對應自己的數據庫。
單體架構所有的模塊開發所使用的技術一樣，微服務每個模塊都可以使用不同的開發技術，開發模式更靈活。
什么樣的項目適合微服務
微服務可以按照業務功能本身的獨立性來劃分，如果系統提供的業務是非常底層的，如：操作系統內核、存儲系統、網絡系統、數據庫系統等等，這類系統都偏底層，功能和功能之間有著緊密的配合關系，如果強制拆分為較小的服務單元，會讓集成工作量急劇上升，并且這種人為的切割無法帶來業務上的真正的隔離，所以無法做到獨立部署和運行，也就不適合做成微服務了。
能不能做成微服務，取決于四個要素：
小：微服務體積小，2 pizza 團隊。
獨：能夠獨立的部署和運行。
輕：使用輕量級的通信機制和架構。
松：為服務之間是松耦合的。
微服務優勢與缺點
特性
每個微服務可獨立運行在自己的進程里；
一系列獨立運行的微服務共同構建起了整個系統；
每個服務為獨立的業務開發，一個微服務一般完成某個特定的功能，比如：訂單管理，用戶管理等；
微服務之間通過一些輕量級的通信機制進行通信，例如通過REST API或者RPC的方式進行調用。
特點
易于開發和維護
- 由于微服務單個模塊就相當于一個項目，開發這個模塊我們就只需關心這個模塊的邏輯即可，代碼量和邏輯復雜度都會降低，從而易于開發和維護。
啟動較快
- 這是相對單個微服務來講的，相比于啟動單體架構的整個項目，啟動某個模塊的服務速度明顯是要快很多的。
局部修改容易部署
- 在開發中發現了一個問題，如果是單體架構的話，我們就需要重新發布并啟動整個項目，非常耗時間，但是微服務則不同，哪個模塊出現了bug我們只需要解決那個模塊的bug就可以了，解決完bug之后，我們只需要重啟這個模塊的服務即可，部署相對簡單，不必重啟整個項目從而大大節約時間。
技術棧不受限
- 比如訂單微服務和電影微服務原來都是用java寫的，現在我們想把電影微服務改成nodeJs技術，這是完全可以的，而且由于所關注的只是電影的邏輯而已，因此技術更換的成本也就會少很多。
按需伸縮
- 我們上面說了單體架構在想擴展某個模塊的性能時不得不考慮到其它模塊的性能會不會受影響，對于我們微服務來講，完全不是問題，電影模塊通過什么方式來提升性能不必考慮其它模塊的情況。
缺點
運維要求較高
- 對于單體架構來講，我們只需要維護好這一個項目就可以了，但是對于微服務架構來講，由于項目是由多個微服務構成的，每個模塊出現問題都會造成整個項目運行出現異常，想要知道是哪個模塊造成的問題往往是不容易的，因為我們無法一步一步通過debug的方式來跟蹤，這就對運維人員提出了很高的要求。
分布式的復雜性
- 對于單體架構來講，我們可以不使用分布式，但是對于微服務架構來說，分布式幾乎是必會用的技術，由于分布式本身的復雜性，導致微服務架構也變得復雜起來。
接口調整成本高
- 比如，用戶微服務是要被訂單微服務和電影微服務所調用的，一旦用戶微服務的接口發生大的變動，那么所有依賴它的微服務都要做相應的調整，由于微服務可能非常多，那么調整接口所造成的成本將會明顯提高。
重復勞動
- 對于單體架構來講，如果某段業務被多個模塊所共同使用，我們便可以抽象成一個工具類，被所有模塊直接調用，但是微服務卻無法這樣做，因為這個微服務的工具類是不能被其它微服務所直接調用的，從而我們便不得不在每個微服務上都建這么一個工具類，從而導致代碼的重復。
微服務開發框架
目前微服務的開發框架，最常用的有以下四個：
Spring Cloud：http://projects.spring.io/spring-cloud（現在非常流行的微服務架構）
Dubbo：http：//dubbo.io
Dropwizard：http://www.dropwizard.io （關注單個微服務的開發）
Consul、etcd&etc.（微服務的模塊）
更多精彩內容請關注“IT實戰聯盟”公眾號哦~~~~
