想做一篇微服務框架的學習
zookeeper是hadoop框架的一部分，用于提供命名空間和分布式協調服務。但它的運行不依賴于hadoop或者其他組件。因此，在微服務框架中使用的也比較頻繁。
比如在當前公司實習遇到的大數據項目，本質上也是一種微服務框架。
---什么是微服務框架？
回答轉自知乎
微服務框架強調的第一個重點就是業務系統需要徹底地組件化和服務化，原有的單個業務系統會拆分成多個可以獨立開發、設計、運行和運維的小應用。這些應用之間通過服務完成交互和集成。且每個小應用從前端web ui，到控制層，邏輯層，數據庫訪問，數據庫都是完全獨立的一套。每個小應用除了完成自身本身的業務以外，重點是還需要消費外部其他應用暴露的服務，同時也將自身的能力向外發布服務。
如果用一句話來談SOA和微服務的區別，就是微服務不再強調傳統SOA架構里面比較重的ESB企業服務總線，同時SOA的思想進入到單個業務系統內部實現真正的組件
------------微服務框架優點與不足
單體應用帶來的困難有哪些？
1）系統復雜：內部多個模塊緊耦合，關聯依賴復雜，牽一發而動全身
2）運行困難：變更升級的影響分析困難，任何一個小小的修改都可能導致單體應用整體出現故障
3）無法擴展：無法拆分部署，出現性能瓶頸后往往只能增加服務器或者增加集群節點，但DB問題難解決
而微服務框架正好對這樣一些問題有很好的解決辦法。
微服務框架記住下面一些重點：1.足以構成一個小應用；2. 服務之間僅僅通過service api進行訪問 3. 運行在云虛擬機或者更輕的Docker容器【一個開源的應用容器引擎，目前不是特別懂這個東西】上
API--這是微服務框架中需要考慮的一個重要問題，用更加輕量和高性能的方式來解決微服務的管控和治理問題。對于負載均衡，緩存，路由，訪問控制，服務代理，監控，日志等都是需要重點考慮的。
-----------API構建微服務
下面有舉個栗子說明
引入場景，一個亞馬遜網址的手機APP訂單查看頁面，如果是一個單體應用，那么所有的頁面都通過單體應用統一的地址提供多個service API獲取。如果是轉換為微服務架構后可以看到對于會員管理，商品管理，訂單管理，財務結算等，拆分到了不同的模塊當中，需要從不同的地址調用不同的微服務。
在這里我們對于客戶端和微服務端點對點的通信提出了如下三個問題:
1. 問題一：客戶端暴露的需求和每個微服務暴露的細粒度API不匹配
2. 問題二：部分服務使得協議對web并不友好，如二進制RPC或AMQP消息等
3. 問題三：微服務架構難以重構，比如服務拆分和服務組合的場景
API網關為客戶端提供了接入服務器的統一入口，很容易想到設計模式中的Faccade模式。它可能還具備負載均衡等等一系列能力。客戶端的所有請求都必須通過API網關，再轉發到對應的微服務上，API網關經常會通過協調多個微服務并合并結果來處理一個請求，它可以在web協議和內部協議之間進行轉換
API網關還能為用戶定制API，比如API網關可以提供一個端點[/productdetails?productid=xxx]
對于API網關的優點，其實是類似傳統ESB企業服務總線的優點，即實現服務透明，同時對于服務運行中的日志，安全，路由，緩存等問題進行統一的配置和處理，而不需要每個API實現時都去考慮，如ALI開源的Dubbo服務總線即可以看做一個API網關的實現。
API網關和ESB的一些重要區別在于API網關更加地輕量和高性能，它不需要去考慮太多遺留系統和諸多協議的適配，其次也不需要考慮服務集成過程中大量數據的轉換和映射。同時為了提升網關的性能，一般API網關在實現過程中不會去記錄詳細的數據傳輸日志，或者類似于Dubbo架構數據傳輸根本就不會經過API網關。
