Dubbo
Dubbo是 阿裡巴巴公司開源的一個高性能優秀的服務架構，使得應用可通過高性能的 RPC 實作服務的輸出和輸入功能，可以和 Spring架構無縫內建。
Dubbo是一款高性能、輕量級的開源Java RPC架構，它提供了三大核心能力：面向接口的遠端方法調用，智能容錯和負載均衡，以及服務自動注冊和發現。
Dubbo是一個分布式服務架構，緻力于提供高性能和透明化的RPC遠端服務調用方案，是阿裡巴巴SOA服務化治理方案的核心架構，每天為2,000+個服務提供3,000,000,000+次通路量支援，并被廣泛應用于阿裡巴巴集團的各成員站點。
Dubbo是Alibaba開源的分布式服務架構，它最大的特點是按照分層的方式來架構，使用這種方式可以使各個層之間解耦合（或者最大限度地松耦合）。從服務模型的角度來看，Dubbo采用的是一種非常簡單的模型，要麼是提供方提供服務，要麼是消費方消費服務，是以基于這一點可以抽象出服務提供方（Provider）和服務消費方（Consumer）兩個角色。Dubbo架構使得使用者可以像調用本地方法一樣調用遠端方法，而這一切隻需要簡單的配置。Dubbo完全相容Spring配置方式注入，也與Spring boot無縫整合。
RPC:
Dubbo官網:http://dubbo.io/
Dubbo的主要核心部件 ：
Remoting: 網絡通信架構，實作了 sync-over-async 和request-response 消息機制.
RPC: 一個遠端過程調用的抽象，支援負載均衡、容災和叢集功能
Registry: 服務目錄架構用于服務的注冊和服務事件釋出和訂閱
工作原理：
Provider
暴露服務方稱之為“服務提供者”。
Consumer
調用遠端服務方稱之為“服務消費者”。
Registry
服務注冊與發現的中心目錄服務稱之為“服務注冊中心”。
Monitor
統計服務的調用次數和調用時間的日志服務稱之為“服務監控中心”。
(1) 連通性：
注冊中心負責服務位址的注冊與查找，相當于目錄服務，服務提供者和消費者隻在啟動時與注冊中心互動，注冊中心不轉發請求，壓力較小
監控中心負責統計各服務調用次數，調用時間等，統計先在記憶體彙總後每分鐘一次發送到監控中心伺服器，并以報表展示
服務提供者向注冊中心注冊其提供的服務，并彙報調用時間到監控中心，此時間不包含網絡開銷
服務消費者向注冊中心擷取服務提供者位址清單，并根據負載算法直接調用提供者，同時彙報調用時間到監控中心，此時間包含網絡開銷
注冊中心，服務提供者，服務消費者三者之間均為長連接配接，監控中心除外
注冊中心通過長連接配接感覺服務提供者的存在，服務提供者當機，注冊中心将立即推送事件通知消費者
注冊中心和監控中心全部當機，不影響已運作的提供者和消費者，消費者在本地緩存了提供者清單
注冊中心和監控中心都是可選的，服務消費者可以直連服務提供者
(2) 健壯性：
監控中心宕掉不影響使用，隻是丢失部分采樣資料
資料庫宕掉後，注冊中心仍能通過緩存提供服務清單查詢，但不能注冊新服務
注冊中心對等叢集，任意一台宕掉後，将自動切換到另一台
注冊中心全部宕掉後，服務提供者和服務消費者仍能通過本地緩存通訊
服務提供者無狀态，任意一台宕掉後，不影響使用
服務提供者全部宕掉後，服務消費者應用将無法使用，并無限次重連等待服務提供者恢複
(3) 伸縮性：
注冊中心為對等叢集，可動态增加機器部署執行個體，所有用戶端将自動發現新的注冊中心
服務提供者無狀态，可動态增加機器部署執行個體，注冊中心将推送新的服務提供者資訊給消費者
原理圖：
Dubbo 的特性:
面向接口代理的高性能RPC調用
提供高性能的基于代理的遠端調用能力，服務以接口為粒度，為開發者屏蔽遠端調用底層細節。
智能負載均衡
内置多種負載均衡政策，智能感覺下遊節點健康狀況，顯著減少調用延遲，提高系統吞吐量。
服務自動注冊與發現
支援多種注冊中心服務，服務執行個體上下線實時感覺。
高度可擴充能力
遵循微核心+插件的設計原則，所有核心能力如Protocol、Transport、Serialization被設計為擴充點，平等對待内置實作和第三方實作。
運作期流量排程
内置條件、腳本等路由政策，通過配置不同的路由規則，輕松實作灰階釋出，同機房優先等功能。
可視化的服務治理與運維
提供豐富服務治理、運維工具：随時查詢服務中繼資料、服務健康狀态及調用統計，實時下發路由政策、調整配置參數。
注意:搭建dubbo項目時要先保證機器上有zookeeper,這裡就不再寫了。
ZipKin
Zipkin是什麼
Zipkin分布式跟蹤系統；它可以幫助收集時間資料，解決在microservice架構下的延遲問題；它管理這些資料的收集和查找；Zipkin的設計是基于谷歌的Google Dapper論文。
每個應用程式向Zipkin報告定時資料，Zipkin UI呈現了一個依賴圖表來展示多少跟蹤請求經過了每個應用程式；如果想解決延遲問題，可以過濾或者排序所有的跟蹤請求，并且可以檢視每個跟蹤請求占總跟蹤時間的百分比。
為什麼使用Zipkin
随着業務越來越複雜，系統也随之進行各種拆分，特别是随着微服務架構和容器技術的興起，看似簡單的一個應用，背景可能有幾十個甚至幾百個服務在支撐；一個前端的請求可能需要多次的服務調用最後才能完成；當請求變慢或者不可用時，我們無法得知是哪個背景服務引起的，這時就需要解決如何快速定位服務故障點，Zipkin分布式跟蹤系統就能很好的解決這樣的問題。
Zipkin下載下傳和啟動
官方提供了三種方式來啟動，這裡使用第二種方式來啟動;
wget -O zipkin.jar 'https://search.maven.org/remote_content?g=io.zipkin.java&a=zipkin-server&v=LATEST&c=exec'
java -jar zipkin.jar
首先下載下傳zipkin.jar，然後直接使用-jar指令運作，要求jdk8以上版本；
[[email protected] ~]# java -jar zipkin.jar
********
** **
* *
** **
** **
** **
** **
********
****
****
**** ****
****** **** ***
****************************************************************************
******* **** ***
**** ****
**
**
***** ** ***** ** ** ** ** **
** ** ** * *** ** **** **
** ** ***** **** ** ** ***
****** ** ** ** ** ** ** **
:: Powered by Spring Boot :: (v1.5.8.RELEASE)
......
on || application/json]}" onto public java.lang.Object org.springframework.boot.actuate.endpoint.mvc.HealthMvcEndpoint.invoke(javax.servlet.http.HttpServletRequest,java.security.Principal)
2017-12-06 22:09:17.498 INFO 7555 --- [ main] o.s.j.e.a.AnnotationMBeanExporter : Registering beans for JMX exposure on startup
2017-12-06 22:09:17.505 INFO 7555 --- [ main] o.s.c.support.DefaultLifecycleProcessor : Starting beans in phase 0
2017-12-06 22:09:17.789 INFO 7555 --- [ main] b.c.e.u.UndertowEmbeddedServletContainer : Undertow started on port(s) 9411 (http)
2017-12-06 22:09:17.794 INFO 7555 --- [ main] zipkin.server.ZipkinServer : Started ZipkinServer in 16.867 seconds (JVM running for 19.199)
基于Undertow WEB伺服器，提供對外端口：9411，可以打開浏覽器通路http://ip:9411
詳細參考：https://zipkin.io/pages/quick...
Zipkin架構
跟蹤器(Tracer)位于你的應用程式中，并記錄發生的操作的時間和中繼資料,提供了相應的類庫，對使用者的使用來說是透明的，收集的跟蹤資料稱為Span;
将資料發送到Zipkin的儀器化應用程式中的元件稱為Reporter,Reporter通過幾種傳輸方式之一将追蹤資料發送到Zipkin收集器(collector)，
然後将跟蹤資料進行存儲(storage),由API查詢存儲以向UI提供資料。
架構圖如下：
1.Trace
Zipkin使用Trace結構表示對一次請求的跟蹤，一次請求可能由背景的若幹服務負責處理，每個服務的處理是一個Span，Span之間有依賴關系，Trace就是樹結構的Span集合；
2.Span
每個服務的處理跟蹤是一個Span，可以了解為一個基本的工作單元，包含了一些描述資訊：id，parentId，name，timestamp，duration，annotations等，例如：
{
"traceId": "bd7a977555f6b982",
"name": "get-traces",
"id": "ebf33e1a81dc6f71",
"parentId": "bd7a977555f6b982",
"timestamp": 1458702548478000,
"duration": 354374,
"annotations": [
{
"endpoint": {
"serviceName": "zipkin-query",
"ipv4": "192.168.1.2",
"port": 9411
},
"timestamp": 1458702548786000,
"value": "cs"
}
],
"binaryAnnotations": [
{
"key": "lc",
"value": "JDBCSpanStore",
"endpoint": {
"serviceName": "zipkin-query",
"ipv4": "192.168.1.2",
"port": 9411
}
}
]
}
traceId：标記一次請求的跟蹤，相關的Spans都有相同的traceId；
id：span id；
name：span的名稱，一般是接口方法的名稱；
parentId：可選的id，目前Span的父Span id，通過parentId來保證Span之間的依賴關系，如果沒有parentId，表示目前Span為根Span；
timestamp：Span建立時的時間戳，使用的機關是微秒（而不是毫秒），所有時間戳都有錯誤，包括主機之間的時鐘偏差以及時間服務重新設定時鐘的可能性，
出于這個原因，Span應盡可能記錄其duration；
duration：持續時間使用的機關是微秒（而不是毫秒）；
annotations：注釋用于及時記錄事件；有一組核心注釋用于定義RPC請求的開始和結束；
cs:Client Send，用戶端發起請求；
sr:Server Receive，伺服器接受請求，開始處理；
ss:Server Send，伺服器完成處理，給用戶端應答；
cr:Client Receive，用戶端接受應答從伺服器；
binaryAnnotations：二進制注釋，旨在提供有關RPC的額外資訊。
3.Transport
收集的Spans必須從被追蹤的服務運輸到Zipkin collector，有三個主要的傳輸方式：HTTP, Kafka和Scribe；
4.Components
有4個元件組成Zipkin：collector，storage，search，web UI
collector：一旦跟蹤資料到達Zipkin collector守護程序，它将被驗證，存儲和索引，以供Zipkin收集器查找；
storage：Zipkin最初資料存儲在Cassandra上，因為Cassandra是可擴充的，具有靈活的模式，并在Twitter中大量使用；但是這個元件可插入，除了Cassandra之外，還支援ElasticSearch和MySQL；
search：一旦資料被存儲和索引，我們需要一種方法來提取它。查詢守護程序提供了一個簡單的JSON API來查找和檢索跟蹤，主要給Web UI使用；
web UI：建立了一個GUI，為檢視痕迹提供了一個很好的界面；Web UI提供了一種基于服務，時間和注釋檢視跟蹤的方法。