1、TECH.研發(fā)中心,目錄,目錄,1.1 框架介紹,Service1,Service3,Service2,應(yīng)用,Cloud Bus消息管理,Hystrix熔斷,Eureka服務(wù)發(fā)現(xiàn),Swagger接口管理,Turbine,Ribbon負(fù)載均衡,應(yīng)用服務(wù)1,JWT Token Relay,Access Check,Load Balancer (Ribbon),服務(wù)網(wǎng)關(guān) Zuul Server,應(yīng)用服務(wù)2,認(rèn)證服務(wù),系統(tǒng)/租戶,用戶,角色,服務(wù)權(quán)限/菜單,LDAP用戶,其他-更細(xì)服務(wù),微 服 務(wù),營銷應(yīng)用,SSO登錄,訪問菜單,調(diào)用各應(yīng)用服務(wù),調(diào)用驗證服務(wù)獲取UUID,調(diào)用訪問服務(wù),UUID,UUI

2、D,其他應(yīng)用,Choerodon Framework 基于微服務(wù)架構(gòu)模式，使得每個服務(wù)獨立，可靈活擴展。和單體架構(gòu)不同，微服務(wù)架構(gòu)是由一系列職責(zé)單一的細(xì)粒度服務(wù)構(gòu)成的分布式網(wǎng)狀結(jié)構(gòu)，其技術(shù)選型是去中心化的。在這種模式下，每個微服務(wù)團隊有充分自由根據(jù)自身服務(wù)的需求和行業(yè)發(fā)展?fàn)顩r選擇適合的技術(shù)棧?？蓪崿F(xiàn)服務(wù)注冊、發(fā)現(xiàn)和負(fù)載均衡。,控制項目復(fù)雜度 將原來的單體式應(yīng)用拆解成多個服務(wù)運行在不同進(jìn)程中，這樣可以只針對相應(yīng)的服務(wù)進(jìn)行修改，部署對應(yīng)的服務(wù)進(jìn)程，控制復(fù)雜性,業(yè)務(wù)模塊化，加速迭代速度 松耦合的結(jié)構(gòu)，讓每個開發(fā)團隊都可以根據(jù)自身情況去選擇更適合的技術(shù)與工具，進(jìn)行更有效更靈活的開發(fā)。,獨立部署，提升效

3、率 將復(fù)雜的業(yè)務(wù)邏輯根據(jù)功能剝離開來，讓它們具備獨立的進(jìn)程，每個服務(wù)也就可以獨立的編譯打包部署。,錯誤隔離 每個服務(wù)都具有獨立性，提高系統(tǒng)的容錯性。不會因為單一服務(wù)發(fā)生延遲，導(dǎo)致所有應(yīng)用資源（線程，隊列等）被耗盡，造成雪崩效應(yīng)。,1.2 架構(gòu)演變,水平分層架構(gòu)（單體架構(gòu)） 垂直分層架構(gòu)（分布式架構(gòu)） 面向服務(wù)架構(gòu)（SOA） 前后端分離架構(gòu) 微服務(wù)架構(gòu),All in one,Vertical,SOA,Microservice,1.2 架構(gòu)演變 單體架構(gòu),1.2 架構(gòu)演變 微服務(wù)架構(gòu),1.3 微服務(wù)架構(gòu)設(shè)計模式,1.4 微服務(wù)劃分,微服務(wù)架構(gòu)的目標(biāo)是加速軟件開發(fā)通過允許持續(xù)交付/部署。 簡化了測試

4、和組件可以獨立部署 每個團隊必須自主擁有一個或多個服務(wù) 服務(wù)體系結(jié)構(gòu)是相對穩(wěn)定的 開發(fā)團隊是圍繞交付業(yè)務(wù)價值,而不是技術(shù)特點 服務(wù)是有凝聚力和松散耦合,但是這些好處不會自動保證。他們只能通過應(yīng)用程序的仔細(xì)的功能分解成服務(wù)。,1.4 微服務(wù)劃分 按照業(yè)務(wù)劃分,定義服務(wù)相應(yīng)的業(yè)務(wù)功能。 業(yè)務(wù)能力是一種從業(yè)務(wù)架構(gòu)建模概念。 業(yè)務(wù)能力通常對應(yīng)于一個業(yè)務(wù)對象。 業(yè)務(wù)功能經(jīng)常被組織成一個多級層次結(jié)構(gòu)。 eg.: 訂單管理負(fù)責(zé)訂單，用戶管理負(fù)責(zé)用戶,1.4 微服務(wù)劃分 按照領(lǐng)域劃分,服務(wù)對應(yīng)領(lǐng)域驅(qū)動設(shè)計(DDD)的子域。 DDD是指應(yīng)用程序的問題空間-業(yè)務(wù)領(lǐng)域。 領(lǐng)域是由多個子域。 每個子域?qū)?yīng)于不同的業(yè)務(wù)

5、的一部分。 領(lǐng)域的劃分需要對業(yè)務(wù)能力有一定的理解。,1.5 微服務(wù)劃分 注意事項,用微服務(wù)需要注意業(yè)務(wù)邊界，一般關(guān)聯(lián)性強的業(yè)務(wù)不要拆分成微服務(wù)而是需要放在一個服務(wù)里，這樣可以避免服務(wù)于關(guān)聯(lián)服務(wù)間的頻繁Join，應(yīng)用起來效率低 互聯(lián)網(wǎng)企業(yè)的一些應(yīng)用其實比較簡單，表一般30張不到甚至更少，只是有海量用戶、高并發(fā)應(yīng)用需求，這種比較適合微服務(wù)，可以靈活做服務(wù)發(fā)布、升降級服務(wù)。可以按照應(yīng)用顆粒度去拆分服務(wù) 企業(yè)內(nèi)部應(yīng)用，一般不適合應(yīng)用微服務(wù)。要用可以參考EBS的各個模塊，模塊內(nèi)關(guān)聯(lián)性強，不拆分而作為一個服務(wù)。模塊間可以拆分服務(wù)，模塊與模塊間的服務(wù)Join，也盡量避免直接在一個服務(wù)里Join，而是通過在應(yīng)

6、用層面去考慮服務(wù)分步調(diào)用，比如先查出采購訂單信息，另外再點擊查看明細(xì)能查到庫存信息，而非一次性就將采購和庫存都查出來。 需要注意持續(xù)監(jiān)控服務(wù)質(zhì)量，去發(fā)現(xiàn)性能問題、開發(fā)問題等，再不斷迭代去拆分服務(wù) 微服務(wù)的數(shù)據(jù)一致性，一般是先考慮實現(xiàn)最終一致性，可以用異步補償機制，監(jiān)控消息隊列中的消息執(zhí)行情況，根據(jù)消息執(zhí)行的不同階段，去自動回滾到原始狀態(tài)做補償 與SOA的區(qū)別，SOA中有服務(wù)合并（Split-Join）、服務(wù)報文&協(xié)議轉(zhuǎn)換，能更好的支持更細(xì)顆粒度的服務(wù)。這些微服務(wù)暫時還達(dá)不到；微服務(wù)具備服務(wù)鏈的概念，可以更好的監(jiān)控一個流程的情況,目錄,2.1 整體架構(gòu),API Service,Composite

7、 Service,Core Service,Choerodon Framework架構(gòu)： 基于Spring Cloud Oauth Server基于Spring Security Discovery使用Eureka Configuration Server使用Spring Cloud默認(rèn)的Config Server. AMQP Message Monitor Dashboard Trace Analysis 名詞： CB=Circuit Breaker (Hystrix)斷路器 LB=Load Balancer (Ribbon)負(fù)載均衡,基礎(chǔ)架構(gòu)組件,輔助組件(功能),業(yè)務(wù)功能,目錄,3.1

8、服務(wù)清單,3.2 組件：服務(wù)注冊與服務(wù)發(fā)現(xiàn),服務(wù)調(diào)用方,LB,服務(wù)發(fā)現(xiàn),負(fù)載均衡與服務(wù)調(diào)用,服務(wù)注冊與健康檢查,服務(wù)注冊中心,服務(wù)注冊中心,服務(wù)注冊中心,服務(wù)提供方,服務(wù)提供方,服務(wù)提供方,3.2 組件：服務(wù)網(wǎng)關(guān),主要功能： 服務(wù)反向路由 容錯 安全認(rèn)證 限流 API集中管理 灰度發(fā)布,3.2 組件：認(rèn)證服務(wù),Client,api-gateway,認(rèn)證服務(wù),用戶數(shù)據(jù),UUID轉(zhuǎn)換為內(nèi)部JWT,gateway-helper,基于OAuth2.0 + Spring Security實現(xiàn)認(rèn)證與授權(quán) 外部使用Oauth uuid token，內(nèi)部服務(wù)之間使用JWT,各個服務(wù)處理JWT,3.2 組件：服

9、務(wù)配置中心,1.提交配置更新,2. 通知配置更改,3.發(fā)送消息通知 服務(wù)更新配置,4.收取消息,5.拉取最新配置 更新服務(wù)配置,管理服務(wù),配置中心,Spring Cloud Bus,Service A,Service B,Service C,Service A,Service A,6.拉取最新配置,3.2 組件：服務(wù)狀態(tài)監(jiān)控,服務(wù)A,服務(wù)B,服務(wù)C,服務(wù)網(wǎng)關(guān),AMQP Message Bus,性能數(shù)據(jù)收集 Turbine,Hystrix Dashboard,3.3 組件：調(diào)用鏈,Client,API Gateway,AMQP Message Bus,調(diào)用鏈日志分析 Zipkin Server,

10、3.3 功能：權(quán)限,角色分為三層，分別是全局層，組織層，項目層。 權(quán)限同樣分為三層。 每一層級的角色只能分配對應(yīng)層級的權(quán)限。,3.3 功能：權(quán)限,源碼管理,項目,組織,資源,源碼管理,instance_a,instance_b,project_1,project_2,user_a code.admin,user_b code.admin,organization,ldap,3.4 可靠事件數(shù)據(jù)一致性-本地事件表,Service,業(yè)務(wù)表,事件表,本地事務(wù),事件投遞,E1,E2,E3,E4,Service,業(yè)務(wù)表,1.同一個本地事務(wù)中記錄業(yè)務(wù)數(shù)據(jù)和事件數(shù)據(jù),2.事件投遞服務(wù)向消息隊發(fā)送消息，如果發(fā)

11、送成功能，刪除事件。,3.訂閱事件，使用消息隊列ack，或類似機制保證消息消費,本地事務(wù)保證業(yè)務(wù)表與事件表的一致性，不會產(chǎn)生不一致,事件投遞分為兩個步驟： 1，發(fā)送消息 2，更新事件表，刪除已經(jīng)處理的事件 這里會有一個不一致的可能性，如果1成功能，2不成功能，則會造成消息重復(fù)發(fā)布，這個可以由消息處理服務(wù)的冪等性來保證,消息處理分為兩個步驟： 1，執(zhí)行消息所需的業(yè)務(wù)邏輯 2，返回事件消息ack，標(biāo)記已經(jīng)消費 這里的不一致性為1成功，2不成，會造成消息的重復(fù)處理，這里面需要保證處理邏輯的冪等性，一個消息，一次只處理一次。,3.4 可靠事件數(shù)據(jù)一致性-外部事件表,Service,業(yè)務(wù)表,E1,E2,

12、E3,E4,Service,業(yè)務(wù)表,事件服務(wù),事件消息,事件投遞,事件表,事件確認(rèn),1，發(fā)事件開始消息,2，開始業(yè)邏輯,3，發(fā)事件完成消息,4，將已經(jīng)完成的事件，發(fā)送到消息隊列,5，消費消息完成一致性業(yè)務(wù)邏輯,6，確認(rèn)開始狀態(tài)的消息是否完成,產(chǎn)生數(shù)據(jù)不一致的情況有： a,步驟1完成，2，3都沒有執(zhí)行 b,步驟1,2完成，3沒有執(zhí)行 上面兩種情況，需要消息產(chǎn)生服務(wù)提供事件確認(rèn)接口，事件服務(wù)在事件表中發(fā)現(xiàn)消息的狀態(tài)是開始，而且在一定時間內(nèi)沒有標(biāo)記為完成，則會調(diào)用消息產(chǎn)生服務(wù)的確認(rèn)接口進(jìn)行確認(rèn)。,4，5，這兩個步驟與本地事件表的邏輯一致。,目錄,4.1 組件清單,目錄,5.1 開發(fā)流程,開發(fā)環(huán)境搭建

13、 軟件安裝(Windows) 基礎(chǔ)環(huán)境準(zhǔn)備 數(shù)據(jù)初始化 運行 開發(fā)Demo程序 項目需求 新建項目 初始化數(shù)據(jù)庫 編寫代碼類 集成Choerodon項目配置 swagger測試,5.2 開發(fā)規(guī)范,本地開發(fā)開啟兩種規(guī)范檢查 一種為sonarQube的規(guī)范檢查 一種為基于sun和google的checkStyle規(guī)范檢查。,開發(fā)人員local,5.3 開發(fā)模式,K8S服務(wù),服務(wù)網(wǎng)關(guān),認(rèn)證 服務(wù),注冊 服務(wù),調(diào)用鏈 監(jiān)控,應(yīng)用 監(jiān)控,配置 服務(wù),AMQP消息服務(wù),用戶服務(wù),框架服務(wù),管理服務(wù),Mysql,Redis,Kafka,vpn,服務(wù)網(wǎng)關(guān),用戶服務(wù) 本地開發(fā),瀏覽器,服務(wù)網(wǎng)關(guān),5.4 資料參考

14、,Spring boot：https:/docs.spring.io/spring-boot/docs/1.5.3.RELEASE/reference/htmlsingle/ Spring cloud：http:/cloud.spring.io/spring-cloud-static/Dalston.SR4/single/spring-cloud.html Docker： 開發(fā)文檔：https:/rdc.hand-,目錄,6.1 DevOps 流程,1.提交代碼,2.觸發(fā)gitlab-ci,Gitlab代碼庫,Gitlab CI,編譯,初始化測試數(shù)據(jù),測試,生成Docker鏡像,部署到Test環(huán)境,3.使用Kubernetes 調(diào)度docker容器 執(zhí)行編譯，測試，打包,Docker鏡像