微服務(wù)與 DevOps實(shí)踐：技術(shù)架構(gòu)與組織架構(gòu) | IDCF
一、概述
從設(shè)計原則上來講，微服務(wù)架構(gòu)遵循 SOA 的設(shè)計原則。 小的、可重用的服務(wù)并不一定是微服務(wù)，微服務(wù)架構(gòu)強(qiáng)調(diào)敏捷、獨(dú)立開發(fā)、獨(dú)立部署、獨(dú)立擴(kuò)展，重用在某種程度上會影響敏捷性。
敏捷性：微服務(wù)不僅可以提高開發(fā)的敏捷性，還可以加速持續(xù)部署（CD），從而使開發(fā)團(tuán)隊能夠盡快部署新的功能。 減少風(fēng)險：由于每個微服務(wù)都是比較小巧并且獨(dú)立部署的，因此可以減少每次部署的風(fēng)險。 適合分布式開發(fā)：微服務(wù)之間依賴程度低，因此可以更加靈活地獨(dú)立開發(fā)。 技術(shù)靈活性：微服務(wù)之間的耦合程度低，因此技術(shù)團(tuán)隊可以根據(jù)不同的特點(diǎn)選擇最合適的技術(shù)棧，例如利用不同的編程語言解決不同的領(lǐng)域問題。 可擴(kuò)展性：一個應(yīng)用有許多微服務(wù)組成，每個微服務(wù)可以根據(jù)需要獨(dú)立擴(kuò)展，而無須對整個應(yīng)用做整體擴(kuò)展。
Bounded Context Context Map Event Sourcing CQRS BASE
現(xiàn)有軟件架構(gòu)是否已經(jīng)服務(wù)化或者按照系統(tǒng)功能做了模塊化切分。 團(tuán)隊的敏捷成熟度如何，是否有足夠的 DevOps 經(jīng)驗(yàn)。 開發(fā)團(tuán)隊是否有足夠的架構(gòu)設(shè)計能力來適應(yīng)采用微服務(wù)所帶來的設(shè)計方法、模式以及技術(shù)架構(gòu)上的巨大差異。 DBA 團(tuán)隊是否有能力和意愿制定新的數(shù)據(jù)管理模式——將數(shù)據(jù)管理的方式由原來的集中管理轉(zhuǎn)變?yōu)槿ブ行幕芾怼?/span> 運(yùn)維團(tuán)隊是否有足夠的能力為微服務(wù)提供全新的環(huán)境管理工具、部署工具和監(jiān)控工具。
從單體應(yīng)用或者傳統(tǒng)分層架構(gòu)的應(yīng)用向服務(wù)化過渡，通過封裝和組合等方式提供對外發(fā)布接口的能力，從而提升應(yīng)用的可訪問性。 通過重構(gòu)將 Domain-Level（領(lǐng)域?qū)用妫┑墓δ苣K轉(zhuǎn)變?yōu)榭梢元?dú)立部署的服務(wù)，從而提升整個應(yīng)用的敏捷性。我們將這種可獨(dú)立部署的服務(wù)稱為 MiniService，其粒度比微服務(wù)粗，因而抽象難度比較低，但是也能在一定程度上獲得微服務(wù)所帶來的敏捷性提升的好處，但是對 DevOps 的基礎(chǔ)設(shè)施等要求沒有微服務(wù)高，因此建議沒有微服務(wù)經(jīng)驗(yàn)的團(tuán)隊可以從 MiniService 開始嘗試。 通過 Feature-Level（特性層面）的抽象，根據(jù)單一職責(zé)原則將 MiniService 拆分成微服務(wù)，從而獲得更高的擴(kuò)展性和敏捷性。
二、融數(shù)數(shù)據(jù)微服務(wù)的架構(gòu)選型
方便開發(fā) 方便遷移 多協(xié)議支持 多語言支持 方便監(jiān)控 方便運(yùn)維
Zuul 提供的 Edge Service 及 API 網(wǎng)關(guān)是完全基于 HTTP 協(xié)議的過濾器實(shí)現(xiàn)的，基于 HTTP 協(xié)議的同步調(diào)用方式會帶來性能的損失，并且缺乏長連接的推送及多路復(fù)用的能力。 Zuul 不能滿足 RPC 調(diào)用的需求，而在大規(guī)模團(tuán)隊協(xié)作的過程中，契約優(yōu)先的開發(fā)方式優(yōu)于代碼優(yōu)先的開發(fā)方式，因此對于應(yīng)用內(nèi)部交互來講，RPC 框架從管理和協(xié)作的角度要優(yōu)于 REST 服務(wù)。
基于對 gRPC 的封裝，構(gòu)建 Service Provider 的全新實(shí)現(xiàn)，替代 REST 服務(wù)。 通過 Proxy 方式，實(shí)現(xiàn) gRPC 與 REST 服務(wù)的相互轉(zhuǎn)換，保持系統(tǒng)兼容性。 進(jìn)行去中心化治理，通過 Proxy 來實(shí)現(xiàn)端點(diǎn)治理，將客戶端治理變?yōu)榉?wù)端治理。 通過擴(kuò)展并集成 Zipkin 實(shí)現(xiàn)服務(wù)鏈路監(jiān)控和運(yùn)行時拓?fù)涫占?/span> 構(gòu)建 Endpoint inventory 服務(wù)，以 semantic versioning 的方式管理服務(wù)版本。 將 Proxy 作為服務(wù)部署的執(zhí)行端點(diǎn)，通過 VIP 綁定，透明化客戶端尋址工作。利用 Proxy 提供輕量級的負(fù)載均衡、流量控制及灰度發(fā)布的功能。
三、設(shè)計思想
面向運(yùn)維的設(shè)計，配合 DevOps 平臺，提供服務(wù)生命周期管理及易于被監(jiān)控的能力。 面向開發(fā)者，合理封裝。開發(fā)者無須了解 gRPC 的具體實(shí)現(xiàn)。 基于 IDL 的契約優(yōu)先的開發(fā)方式。 提供完善的測試框架和 Mock 工具。 提供完善的易于監(jiān)控的能力。
四、總體架構(gòu)
Graeae 架構(gòu)與協(xié)議無關(guān)。該架構(gòu)可以基于 Netty4、線程模型及 buffer pool 進(jìn)行調(diào)整，以減少 GC 壓力并通過線程切換提升性能協(xié)議。 遵循 protocol buffer 協(xié)議，可以做到通用性強(qiáng)、序列化性能好、壓縮效率高。 語言中立，目前整個架構(gòu)支持 Java、Python 和 Go 三種語言的開發(fā)。 引入了熔斷器機(jī)制、流量控制、服務(wù)治理。 基于 Proxy 和 PaaS 平臺進(jìn)行分布式治理監(jiān)控。 使用集成 Zipkin 的調(diào)用鏈監(jiān)控，以及基于 Pinpoint 的 APM 監(jiān)控。 對于該架構(gòu)而言，直接調(diào)用的性能好于反射調(diào)用，且使用 Netty4 線程模型優(yōu)化。
//服務(wù)提供方
public class SmsTemplateApplication {
public static void main(String[] args) {
new SpringApplicationBuilder().sources(SmsTemplateApplication.class)
.web(false).showBanner(false).run(args);
}
}
//服務(wù)實(shí)現(xiàn)
public class SmsTempletServiceImpl implements SmsTemplateService { @Autowired
private SmsTempletDao smsTempletDao;
@Transactional
public DeleteReply deleteById(IdRequest req) { return SmsTemplateReply.newBuilder().build(); }
}
主版本號：當(dāng)做了不兼容的 API 修改時，需要遞增主版本號。 次版本號：當(dāng)做了向下兼容的功能性新增時，需要遞增次版本號。修訂號：當(dāng)做了向下兼容的問題修正時，需要遞增修訂號。
五、對微服務(wù)的支撐
抽象了部署的最小單元——包。 每個微服務(wù)都是由包及其配置組成的，前面提到，服務(wù)框架做了代碼和配置分離，因此這里可以將包和包的配置分離，提供運(yùn)維便利性。 邏輯環(huán)境包括了微服務(wù)、微服務(wù)配置及運(yùn)行微服務(wù)所依賴的 Host 或者 Host Group。 版本化邏輯環(huán)境，方便回滾。
六、DevOps 平臺總體架構(gòu)
七、融數(shù)數(shù)據(jù)面向微服務(wù)的研發(fā)團(tuán)隊介紹
八、總結(jié)
來源：技術(shù)瑣話，內(nèi)容選自《架構(gòu)寶典》 作者：王東 王東，曾任融數(shù)數(shù)據(jù)北京研發(fā)中心 CTO，負(fù)責(zé)微服務(wù)、DevOps 以及大數(shù)據(jù)平臺的研發(fā)和管理工作。曾供職于 IBM、普元、Amazon、OneAPM 等國內(nèi)外知名公司。擁有 15 年以上的 JavaEE 編程和架構(gòu)設(shè)計經(jīng)驗(yàn)，精通 DevOps 和微服務(wù)，曾領(lǐng)導(dǎo)設(shè)計和開發(fā)普元 ESB 產(chǎn)品。熟悉支付相關(guān)的業(yè)務(wù)流程以及各個銀行和支付機(jī)構(gòu)的業(yè)務(wù)處理模式，熟悉應(yīng)用與支付領(lǐng)域的大規(guī)模分布式系統(tǒng)設(shè)計和開發(fā)方法，熟悉電子商務(wù)行業(yè)的業(yè)務(wù)模型。專注于客戶行為分析、營銷、產(chǎn)品和服務(wù)、客戶關(guān)系、線上銷售、物流配送、渠道整合、供應(yīng)鏈集成、售后服務(wù)、預(yù)測和推薦等各個電子商務(wù)主要環(huán)節(jié)的分析和設(shè)計，以及 IT 系統(tǒng)的規(guī)劃和實(shí)施。精通 DDD、Scrum 等軟方開發(fā)和設(shè)計方法論。
評論
圖片
表情