一、Dubbo
Dubbo在前面作為一個RPC框架曾經(jīng)提過，是阿里2012年開源的分布式服務框架。
經(jīng)歷了從單體到垂直應用架構(gòu)、分布式服務架構(gòu)，SOA（彈性計算）的幾個重要的階段的發(fā)展，性能出色，穩(wěn)定性好極累了大量國內(nèi)用戶，經(jīng)過停更及重新開啟，目前已捐獻給Apache開源基金會。
1.Dubbo將服務分為提供者和消費者。通過注冊中心實現(xiàn)服務發(fā)現(xiàn)，它支持ZooKpeer,Redis,Multi和Simple幾種類型的注冊中心，后面兩種由于本身的限制，無法達到生產(chǎn)級別要求。ZooKpeer,Redis相比較來說，ZooKpeer在可靠性上面比 Redis更強， Redis更適合用于緩存的場景。但這里要說的是ZooKpeer,Redis都不是阿里內(nèi)部的實現(xiàn)方案，是開源的橋接實現(xiàn)方案。
下面是使用ZooKpeer作為注冊中心時Dubbo的存儲結(jié)構(gòu)，可以看到Dubbo運行時所有信息都統(tǒng)一存入名稱為Dubbo的根節(jié)點。每個服務會以類全名創(chuàng)建一個節(jié)點，下面分別創(chuàng)建providers和consumers子節(jié)點，用于存儲服務提供者和服務消費者信息，每個提供者和消費者都會在相應節(jié)點創(chuàng)建一個臨時節(jié)點，該臨時節(jié)點以URL存儲服務提供者或消費者的IP，端口，調(diào)用方法等原數(shù)據(jù)，以及傳輸協(xié)議，最大承載連接數(shù)，路由策略配置等，另外還有configurators和routers存儲全局配置和路由。服務提供者啟動時注冊完信息后，消費者啟動也會注冊信息同時監(jiān)聽providers節(jié)點的變化。當有新節(jié)點加入或服務下線，消費者可以自動感知變化。
Duboo 支持多注冊中心同時服務，以分組方式來做隔離。前面講ZooKpeer時，講到常用的客戶端有zkClient和Curator
2.Dubbo提供負載均衡及靈活的負載均衡策略。主要支持隨機，輪詢，最少活躍調(diào)用數(shù)和一致性哈四種策略。
默認時隨機策略，調(diào)用量越大隨機效果越好；輪詢時絕對平均，要求服務節(jié)點能力基本持平，否則會導致大量請求阻塞在服務能力弱的節(jié)點上；最少活躍數(shù)可以讓能力強的多干，能力弱的就少干；一致性哈希主要是在分布式緩存方案中，對于有狀態(tài)的服務使用。
Dubbo為負載均衡提供了可配置的權(quán)重。具體配置代碼參考
<dubbo:reference interface="…" loadbalance=“roundrobin” />
<duboo:reference interface="…">
? <dubbo:method name="…" loadbalance=“roundrobin” />
</ dubbo:reference>
3.Dubbo作為RPC框架，其遠程通信在之前分布式系統(tǒng)通信已經(jīng)詳細講過。
通常口中的Dubbo是框架，而實際上其默認的通信協(xié)議也叫dubbo,當然還有RMI,HTTP,WebService,Thrift等。每個協(xié)議序列號協(xié)議，線程模型，消息派發(fā)方式都有很大區(qū)別。
dubbo通信協(xié)議，采用NIO實現(xiàn)多路復用，對于每個消費者，dubbo協(xié)議的服務提供者都會創(chuàng)建固定數(shù)量的長連接來處理，Dubbo使用線程池處理請求增強并發(fā)效率，不適合傳輸大文件/視頻/高清圖等，適合高并發(fā)的互聯(lián)網(wǎng)小請求。其實現(xiàn)并沒有使用java原生NIO包，而是采用Netty框架（可以通過配置切換為Mina或Grizzly）
支持多種序列化協(xié)議，可以通過配置修改，默認使用Hessian，除此之外還有JSON,Java原生序列化及Dubbo本身序列化協(xié)議。
4.Dubbo支持限流 ，可以在服務端配置也可以在通信協(xié)議上進行全局配置。
5.Dubbo的治理和監(jiān)控這塊，Dubbo本身有一個Dubbo-admin的治理中心為服務提供了分組查詢，配置修改，加權(quán)/降權(quán)，禁用啟用，權(quán)限控制等，便于運維工程師查詢和調(diào)整運行時狀態(tài)。監(jiān)控這塊的 dubbo-monitor主要是統(tǒng)計和分析調(diào)用，傾向于示例程序。
6.DubboX 是當當網(wǎng)對Dubbo的擴展和補充的開源 主要彌補了Dubbo不支持Restful風格的遠程調(diào)用。
二、Spring Cloud
Spring Cloud是基于Spring Boot的侵入式服務治理框架，使統(tǒng)一的編程模型，為配置管理，服務發(fā)現(xiàn)，負載均衡，網(wǎng)關(guān)，斷路器，控制總線，鏈路追蹤等架構(gòu)需求提供了完整方便的實現(xiàn)方案。最新版本是Spring Cloud Finchley.
1.開發(fā)腳手架Spring.io,
2,服務發(fā)現(xiàn)Eureka,Zookpeer,Consul
3.負載均衡 Ribbon
4.熔斷 Hystrix
5.遠程通信Feign
Feign是NetFlix提供的一個聲明式的web服務客戶端，支持JAX-RS及Spring MVC兩種元注解，它整合了Ribbon和Hystrix讓它同時具備負載均衡和熔斷的能力，而Ribbon可以自動整合Eureka，因此通過Feign可以非常方便的把上面所列的服務實現(xiàn)一站式整合。
但是我們也可以看到，這種方便的同時給業(yè)務系統(tǒng)帶來了很大的侵入性，要求全部掌握相關(guān)技術(shù)組件，開發(fā)框架成本還是比較高的。因此在選擇時，不可以唯技術(shù)論。
三、服務鏈路追蹤
在微服務的可觀察性理論中，日志，指標，追蹤時是三個緊密相關(guān)的概念。
追蹤+日志 ------》分布式追蹤
日志+指標 ------》 業(yè)務日志分析
追蹤+指標 ------》應用監(jiān)控 APM
這里主要關(guān)注 分布式追蹤，理論支撐來自google 2010發(fā)表的論文Dapper,a lagre-scale distributed systems tracing infrastructure.
核心實現(xiàn)方法就是在請求上下文中加入 span id和parent id.
阿里的鷹眼系統(tǒng)時比較早實現(xiàn)方案。
常見的開源方案有
1.Apache ZipKin。
2.OpenTracing 作為接口協(xié)議，目前發(fā)展來看，還不能成為跟蹤領(lǐng)域的API標準。
3.Google卡元的OpenCensus 發(fā)展正猛。
國內(nèi)在這一領(lǐng)域的代表時SkyWalking目前也是從個人項目轉(zhuǎn)為Apache 基金項目，功能非常強大，且支持ServiceMesh Istio,有豐富的UI，基本可以實現(xiàn)開箱即用。
由于內(nèi)容太多不再作討論。
具體可以到https://github.com/apache/skywalking/tree/master/docs 詳解閱讀。
