什么是微服務(wù)
首先，微服務(wù)不是一個名字忧风，而是一個架構(gòu)的概念默色，就像Restful不僅僅是描述api的格式，而更多的是描述基于Restful API的架構(gòu)是一樣的狮腿。微服務(wù)架構(gòu)（MSA）是對原來的大型系統(tǒng)而言的腿宰，通過橫向或者縱向、業(yè)務(wù)或者架構(gòu)切分缘厢，將一個大型的系統(tǒng)分散成很多微型小系統(tǒng)吃度。當(dāng)系統(tǒng)復(fù)雜到一定程度時，幾十號人共同維護(hù)一個系統(tǒng)的效率很低昧绣，而且出問題的風(fēng)險也很高规肴。這時候就需要對系統(tǒng)進(jìn)行切分，很早之前提出的SOA系統(tǒng)，和微服務(wù)的架構(gòu)理念不謀而合拖刃。大家現(xiàn)在使用的基于RPC框架（dubbo删壮、thrift等）的架構(gòu)也可以視為一種微服務(wù)。微服務(wù)到現(xiàn)在為止還沒有確切的邊界和定義兑牡，貌似計算機(jī)上很多概念都定義不出來邊界央碟。但是，我理解微服務(wù)之間的通信是http通信均函，傳統(tǒng)rpc調(diào)用方式并不是嚴(yán)格的微服務(wù)亿虽，因為他不能自理，需要依賴苞也，比如可能必須某個rpc服務(wù)Producer存在的情況下洛勉，rpc服務(wù)的Consumer才能啟動起來。所以如迟，下文中的討論收毫，我都以微服務(wù)之間以http通信為前提。
微服務(wù)有什么好處
解耦：對于我們底層程序員而言殷勘，看得見的好處就是解耦此再。我要實現(xiàn)一個功能，可能并不需要很深入的了解別人的代碼玲销，因為程序員嘛输拇，可能都覺得別人的代碼是個渣渣([哭笑不得])。我可以新作一個微服務(wù)贤斜，這個服務(wù)為其他功能提供服務(wù)策吠，又不依賴于原來已有的功能，至于業(yè)務(wù)邏輯瘩绒，可以一邊上手一邊熟悉
內(nèi)聚奴曙，可以獨立部署：意思就是我維護(hù)的這個微服務(wù)，可以獨立部署草讶，對其他服務(wù)不會是強(qiáng)依賴，不會存在因為其他服務(wù)不存在而造成我自己的服務(wù)不能啟動或者不可用的問題
分布式：微服務(wù)架構(gòu)下不存在一個特別大的系統(tǒng)包含很多中心功能炉菲，這樣也能提高容錯性堕战，一個服務(wù)的癱瘓并不會讓整個系統(tǒng)癱瘓
權(quán)限驗證：微服務(wù)是高度內(nèi)聚的服務(wù)，我自己的這個服務(wù)拍霜，我可以定制任意合理規(guī)則嘱丢，而這個規(guī)則又只適用于我自己的服務(wù)。相比于dubbo RPC調(diào)用祠饺，http微服務(wù)調(diào)用的權(quán)限驗證可以更直接更嚴(yán)格更定制化越驻，而rpc調(diào)用時的權(quán)限驗證，我個人始終覺得不能做的很優(yōu)雅
數(shù)據(jù)分開治理，自帶分庫屬性：原來的大系統(tǒng)使用一個數(shù)據(jù)庫缀旁，當(dāng)數(shù)據(jù)很多流量很大時记劈，就會涉及到分庫分表。而微服務(wù)下并巍，每個服務(wù)是否使用數(shù)據(jù)庫目木，數(shù)據(jù)庫是和其他服務(wù)公用還是自建，都有很大靈活性懊渡，即我覺得微服務(wù)自帶分庫分表屬性
系統(tǒng)不會被長期限制在某個技術(shù)棧上刽射，在微服務(wù)的架構(gòu)下，整個系統(tǒng)不會受限于java或者nodejs 或者go剃执，而是大家協(xié)同不沖突誓禁，全部http協(xié)議，json格式
各個模塊的單元測試容易自動化
等
微服務(wù)面臨的挑戰(zhàn)
-
通信肾档，http請求速度慢摹恰，通常一個操作可能會涉及到多個微服務(wù)的相互調(diào)用，如果為了完成一個操作而多次從服務(wù)端調(diào)用不同的微服務(wù)阁最，http請求的耗時可能會成為瓶頸戒祠，如圖1所示。
圖1 - 客戶端與服務(wù)端的通信需要一個 API GateWay：通常情況下速种，客戶端和微服務(wù)們不在一起姜盈，而各個微服務(wù)會集中部署在一個機(jī)房，那微服務(wù)之間的互相調(diào)用是很快速的配阵，但是客戶端和微服務(wù)之間的調(diào)用會是耗時的馏颂。而且，用戶的一個動作不能在客戶端進(jìn)行多次連續(xù)調(diào)用棋傍，這樣一來速度慢救拉，二來會有泄漏系統(tǒng)架構(gòu)的風(fēng)險。
-
通常情況下瘫拣，在客戶端和微服務(wù)架構(gòu)之間會有一個API GateWay亿絮，如圖1變成圖2所示，GateWay最重要的作用是為客戶端提供后臺服務(wù)的聚合麸拄，提供一個統(tǒng)一的服務(wù)出口派昧，解除他們之間的耦合，為了解決API Gateway單點故障點或者性能瓶頸拢切，通常Gateway也是一個集群蒂萎，而且客戶端的訪問控制、賬號管理淮椰、登錄管理等切面通常會在這里處理五慈。
圖2 - 微服務(wù)很多時纳寂，整個鏈路可能很長，調(diào)用失敗的風(fēng)險高泻拦，而且e2e自動化測試會成為一個問題
- 服務(wù)注冊和服務(wù)發(fā)現(xiàn)毙芜，我司有自己的服務(wù)管理系統(tǒng)。
- 分布式事務(wù)聪轿，這個是微服務(wù)系統(tǒng)的大難點爷肝，可能需要根據(jù)自己系統(tǒng)的情況和業(yè)務(wù)需求進(jìn)行定制了，我推薦補(bǔ)償性分布式事務(wù)和基于消息的分布式事務(wù)陆错。
