想做一篇微服務(wù)框架的學(xué)習(xí)
zookeeper是hadoop框架的一部分，用于提供命名空間和分布式協(xié)調(diào)服務(wù)昵济。但它的運(yùn)行不依賴于hadoop或者其他組件智绸。因此，在微服務(wù)框架中使用的也比較頻繁访忿。
比如在當(dāng)前公司實(shí)習(xí)遇到的大數(shù)據(jù)項(xiàng)目瞧栗，本質(zhì)上也是一種微服務(wù)框架。
---什么是微服務(wù)框架海铆？
回答轉(zhuǎn)自知乎
微服務(wù)框架強(qiáng)調(diào)的第一個(gè)重點(diǎn)就是業(yè)務(wù)系統(tǒng)需要徹底地組件化和服務(wù)化迹恐，原有的單個(gè)業(yè)務(wù)系統(tǒng)會(huì)拆分成多個(gè)可以獨(dú)立開發(fā)、設(shè)計(jì)卧斟、運(yùn)行和運(yùn)維的小應(yīng)用殴边。這些應(yīng)用之間通過服務(wù)完成交互和集成。且每個(gè)小應(yīng)用從前端web ui珍语，到控制層锤岸，邏輯層，數(shù)據(jù)庫訪問板乙，數(shù)據(jù)庫都是完全獨(dú)立的一套是偷。每個(gè)小應(yīng)用除了完成自身本身的業(yè)務(wù)以外，重點(diǎn)是還需要消費(fèi)外部其他應(yīng)用暴露的服務(wù)，同時(shí)也將自身的能力向外發(fā)布服務(wù)蛋铆。
如果用一句話來談SOA和微服務(wù)的區(qū)別馋评，就是微服務(wù)不再強(qiáng)調(diào)傳統(tǒng)SOA架構(gòu)里面比較重的ESB企業(yè)服務(wù)總線，同時(shí)SOA的思想進(jìn)入到單個(gè)業(yè)務(wù)系統(tǒng)內(nèi)部實(shí)現(xiàn)真正的組件
------------微服務(wù)框架優(yōu)點(diǎn)與不足
單體應(yīng)用帶來的困難有哪些刺啦？
1）系統(tǒng)復(fù)雜：內(nèi)部多個(gè)模塊緊耦合留特，關(guān)聯(lián)依賴復(fù)雜，牽一發(fā)而動(dòng)全身
2）運(yùn)行困難：變更升級(jí)的影響分析困難洪燥，任何一個(gè)小小的修改都可能導(dǎo)致單體應(yīng)用整體出現(xiàn)故障
3）無法擴(kuò)展：無法拆分部署磕秤，出現(xiàn)性能瓶頸后往往只能增加服務(wù)器或者增加集群節(jié)點(diǎn)，但DB問題難解決
而微服務(wù)框架正好對(duì)這樣一些問題有很好的解決辦法捧韵。
微服務(wù)框架記住下面一些重點(diǎn)：1.足以構(gòu)成一個(gè)小應(yīng)用市咆；2. 服務(wù)之間僅僅通過service api進(jìn)行訪問 3. 運(yùn)行在云虛擬機(jī)或者更輕的Docker容器【一個(gè)開源的應(yīng)用容器引擎，目前不是特別懂這個(gè)東西】上
API--這是微服務(wù)框架中需要考慮的一個(gè)重要問題再来，用更加輕量和高性能的方式來解決微服務(wù)的管控和治理問題蒙兰。對(duì)于負(fù)載均衡，緩存芒篷，路由搜变，訪問控制，服務(wù)代理针炉，監(jiān)控挠他，日志等都是需要重點(diǎn)考慮的。
-----------API構(gòu)建微服務(wù)
下面有舉個(gè)栗子說明
引入場景篡帕，一個(gè)亞馬遜網(wǎng)址的手機(jī)APP訂單查看頁面殖侵，如果是一個(gè)單體應(yīng)用，那么所有的頁面都通過單體應(yīng)用統(tǒng)一的地址提供多個(gè)service API獲取镰烧。如果是轉(zhuǎn)換為微服務(wù)架構(gòu)后可以看到對(duì)于會(huì)員管理拢军，商品管理，訂單管理怔鳖，財(cái)務(wù)結(jié)算等茉唉，拆分到了不同的模塊當(dāng)中，需要從不同的地址調(diào)用不同的微服務(wù)结执。
在這里我們對(duì)于客戶端和微服務(wù)端點(diǎn)對(duì)點(diǎn)的通信提出了如下三個(gè)問題:
1. 問題一：客戶端暴露的需求和每個(gè)微服務(wù)暴露的細(xì)粒度API不匹配
2. 問題二：部分服務(wù)使得協(xié)議對(duì)web并不友好度陆，如二進(jìn)制RPC或AMQP消息等
3. 問題三：微服務(wù)架構(gòu)難以重構(gòu)，比如服務(wù)拆分和服務(wù)組合的場景
API網(wǎng)關(guān)為客戶端提供了接入服務(wù)器的統(tǒng)一入口献幔，很容易想到設(shè)計(jì)模式中的Faccade模式坚芜。它可能還具備負(fù)載均衡等等一系列能力⌒崩眩客戶端的所有請求都必須通過API網(wǎng)關(guān)，再轉(zhuǎn)發(fā)到對(duì)應(yīng)的微服務(wù)上，API網(wǎng)關(guān)經(jīng)常會(huì)通過協(xié)調(diào)多個(gè)微服務(wù)并合并結(jié)果來處理一個(gè)請求铸敏，它可以在web協(xié)議和內(nèi)部協(xié)議之間進(jìn)行轉(zhuǎn)換
API網(wǎng)關(guān)還能為用戶定制API缚忧，比如API網(wǎng)關(guān)可以提供一個(gè)端點(diǎn)[/productdetails?productid=xxx]
對(duì)于API網(wǎng)關(guān)的優(yōu)點(diǎn)，其實(shí)是類似傳統(tǒng)ESB企業(yè)服務(wù)總線的優(yōu)點(diǎn)杈笔，即實(shí)現(xiàn)服務(wù)透明闪水，同時(shí)對(duì)于服務(wù)運(yùn)行中的日志，安全蒙具，路由球榆，緩存等問題進(jìn)行統(tǒng)一的配置和處理，而不需要每個(gè)API實(shí)現(xiàn)時(shí)都去考慮禁筏，如ALI開源的Dubbo服務(wù)總線即可以看做一個(gè)API網(wǎng)關(guān)的實(shí)現(xiàn)持钉。
API網(wǎng)關(guān)和ESB的一些重要區(qū)別在于API網(wǎng)關(guān)更加地輕量和高性能，它不需要去考慮太多遺留系統(tǒng)和諸多協(xié)議的適配篱昔，其次也不需要考慮服務(wù)集成過程中大量數(shù)據(jù)的轉(zhuǎn)換和映射每强。同時(shí)為了提升網(wǎng)關(guān)的性能，一般API網(wǎng)關(guān)在實(shí)現(xiàn)過程中不會(huì)去記錄詳細(xì)的數(shù)據(jù)傳輸日志州刽，或者類似于Dubbo架構(gòu)數(shù)據(jù)傳輸根本就不會(huì)經(jīng)過API網(wǎng)關(guān)空执。
