目錄

舉一反三-論微服務架構(gòu)及其應用

ps: 更多微服務信息

ps: 微服務與SOA區(qū)別

微服務架構(gòu)舉例

微服務的落地技術(shù)

微服務的技術(shù)可大致分為五類

舉一反三-論微服務架構(gòu)及其應用

論微服務架構(gòu)及其應用
微服務提倡將單一應用程序劃分成一組小的服務，服務之間互相協(xié)調(diào)、互相配合，為用戶提供最終價值。每個服務運行在其獨立的進程中，服務與服務間采用輕量級的通信機制互相溝通。在微服務架構(gòu)中，每個服務都是一個相對獨立的個體，每個服務都可以選擇適合于自身的技術(shù)來實現(xiàn)。每個服務的部署都是獨立的，這樣就可以更快地對特定部分的代碼進行部署。
請圍繞“論微服務架構(gòu)及其應用”論題，依次從以下三個方面進行論述。
1、概要敘述你所參與管理或開發(fā)的軟件項目，以及你在其中所承擔的主要工作。
2、簡要描述微服務優(yōu)點。
3、具體闡述如何基于微服務架構(gòu)進行軟件設計實現(xiàn)的。
?

問題1： 同上述。 可以公共使用

問題2：?

?優(yōu)點概述：

技術(shù)選型靈活

在微服務架構(gòu)中，每個服務都是一個相對獨立的個體，每個服務都可以選擇合適于自身的技術(shù)來實現(xiàn)；

因為對于單塊的系統(tǒng)而言，采用一個新的語言，數(shù)據(jù)庫或者框架都會對整個系統(tǒng)產(chǎn)生非常巨大的影響，這樣就導致我們在嘗試新技術(shù)的時候望而卻步。

微服務不同，我們完全可以只在一個微服務中采用新技術(shù)，然后等成熟之后再推廣到其他的服務當中

易于容錯，系統(tǒng)更穩(wěn)定

在單塊系統(tǒng)中一個部分出現(xiàn)問題，可能導致整個系統(tǒng)的問題；

微服務架構(gòu)中，每個服務可以內(nèi)置可用性的解決方案與功能降級方案，所以比單塊系統(tǒng)強大

更易擴展/修改/重構(gòu)

在單塊的系統(tǒng)中我們?nèi)绻獙ο到y(tǒng)進行擴展的話，必須是整體的進行擴展；

使用微服務的架構(gòu)中，可以針對單個服務進行擴展。

在微服務架構(gòu)中，我們可以在需要時輕易的重寫服務，或者刪除不再使用的服務

可獨立部署

對于大型單塊的系統(tǒng)，哪怕是修改了一行代碼，都要對其進行重新的整體的部署。 影響大，風險高。

在微服務中，每個服務都是獨立部署的，而且還可以實現(xiàn)自動化的部署，這樣就可以更快的對特定部分的代碼進行部署。

當某個微服務發(fā)生變更時，無需編譯、部署整個應用。

復雜度可控

????????對于傳統(tǒng)的單塊系統(tǒng)來說，系統(tǒng)越大代碼庫越大，則越難管理，而且還會出現(xiàn)一系列管理方面的問題。

????????每一個微服務專注于單一功能，并通過定義良好的接口清晰地表述服務邊界。由于體積小、復雜度低，每個微服務可由一個小規(guī)模開發(fā)團隊完全掌控(避免代碼庫過大)，易于保持高可維護性，并提高了開發(fā)效率。?

ps: 更多微服務信息

微服務缺點:

1、開發(fā)人員必須處理創(chuàng)建分布式系統(tǒng)的復雜性

2、部署的復雜性

在部署和管理時，由許多不同服務類型組成的系統(tǒng)的操作比較復雜

3、增加內(nèi)存消耗

微服務架構(gòu)用多個服務實例取代了1個單體應用程序?qū)嵗?，如果每個服務都運行在自己的JVM中，那么有多少個服務實例，就會有多少個實例在運行時的內(nèi)存開銷

ps: 微服務與SOA區(qū)別

?共同點：

都是對單體架構(gòu)的拆分

區(qū)別：

微服務架構(gòu)舉例

業(yè)務服務系統(tǒng)各司其職，每個系統(tǒng)只負責自己業(yè)務范圍內(nèi)的職責，比如商品系統(tǒng)僅服務商品相關的服務，創(chuàng)建，更新，查詢，上下架等整個的生命周期并被購物車系統(tǒng)依賴，服務系統(tǒng)之間的邏輯關系清晰，且不同系統(tǒng)間只能通過對方提供的接口做訪問，管理方便，每個系統(tǒng)擁有自己獨立部署服務器，擁有自己的存儲數(shù)據(jù)庫，故障可隔離，配合日志，消息，監(jiān)控，配置中心等分部署微服務下的配合組件做到一個可監(jiān)控，可隔離，又可通信的服務體系

?ps: 核心業(yè)務服務層，也是微服務實現(xiàn)。

微服務的落地技術(shù)

參考：微服務技術(shù)概述_Fall_Flower的博客-CSDN博客

微服務技術(shù)棧：

• 服務集群。?微服務在拆分的時候會根據(jù)業(yè)務功能模塊，把一個單體項目拆分成功能獨立的項目，每個項目完成一部分業(yè)務功能，將來獨立開發(fā)和部署，我們將每個獨立的項目稱為服務，一個大型互聯(lián)網(wǎng)項目往往包含數(shù)百上千的服務，最終形成服務集群

• 注冊中心和配置中心。當一個請求到來的時候，服務a可能會去調(diào)服務c，服務c再去調(diào)服務e，當業(yè)務越來越復雜的時候，服務間的調(diào)用關系就會混亂不堪，想靠人去記錄和維護是不可能的，這時候就要引出注冊中心了。?

注冊中心能記錄每個微服務的ip、端口、能干什么事情，這樣當一個服務需要去調(diào)用另外一個服務時，它不需要去記錄對方的ip、端口信息，只需要去注冊中心拉取即可。

配置中心，它可以統(tǒng)一管理服務集群里面所有服務的配置，如果你需要跟新某個服務的配置，只需要修改配置中心相應配置，它會去通知相關服務去修改配置實現(xiàn)配置的熱更新。

• 服務網(wǎng)關。服務跑起來之后，當用戶來訪問時，究竟去訪問哪個微服務呢，這時候就需要一個網(wǎng)關組件，網(wǎng)關組件還能讓微服務不對外暴露。在訪問的時候還會去做一些負載均衡。

• 分布式緩存和分布式搜索。?數(shù)據(jù)庫將來肯定無法抗住高并發(fā)，因此我們還會加入分布式緩存。

• 消息隊列。在微服務中還需要異步通信的消息隊列組件。在一個請求到來時，假設調(diào)用了服務a，用時10ms，但是服務a調(diào)用了服務c，又用時10ms，而服務a在調(diào)用c的時候自己也不能再處理新的請求，這樣就降低了整體服務效率。

• 分布式日志和系統(tǒng)監(jiān)控鏈路追蹤。這么龐大的集群，若某處發(fā)生問題是很難定位的，所以這時候有引入了分布式日志，分布式日志可以統(tǒng)一的為所有服務日志做存儲、統(tǒng)計、分析，將來出問題就比較好定位了。

• 持續(xù)集成。

  如此龐大的微服務集群，可能會達到數(shù)千上萬的服務，部署也成了一個問題?？咳斯げ渴鹂隙ú滑F(xiàn)實，所以以后還會進行自動化部署?？梢岳?strong>Jenkins工具對微服務項目進行自動化編譯，基于docker做一些打包，形成鏡像，再基于k8s技術(shù)去實現(xiàn)自動化的部署。這一套工具就被稱為：持續(xù)集成

結(jié)合微服務技術(shù)加上持續(xù)集成，這才是完整的微服務技術(shù)棧。

微服務的技術(shù)可大致分為五類

?

實踐1——服務通信 ：遠程的網(wǎng)絡通信調(diào)用函數(shù)的方式就是RPC（Remote Process Call）遠程過程調(diào)用。

一個 RPC 框架基本需要解決 協(xié)議約定、網(wǎng)絡傳輸、服務發(fā)現(xiàn)這三個問題。

①協(xié)議約定問題（Stub） 指的是怎么規(guī)定遠程調(diào)用的語法，怎么傳參數(shù)等

②傳輸協(xié)議問題?（RPCRuntime）指的是在網(wǎng)絡發(fā)生錯誤、重傳、丟包或者有性能問題時怎么辦？

③服務發(fā)現(xiàn)問題?（插件比如:etcd）指的是如何知道服務端有哪些服務可以調(diào)用，從哪個端口訪問？

rpc調(diào)用過程：

1、調(diào)用者（客戶端Client）以本地調(diào)用的方式發(fā)起調(diào)用；
2、Client stub（客戶端存根）收到調(diào)用后，負責將被調(diào)用的方法名、參數(shù)等打包編碼成特定格式的能進行網(wǎng)絡傳輸?shù)南Ⅲw；
3、Client stub將消息體通過網(wǎng)絡發(fā)送給服務端；
4、Server stub（服務端存根）收到通過網(wǎng)絡接收到消息后按照相應格式進行拆包解碼，獲取方法名和參數(shù)；
5、Server stub根據(jù)方法名和參數(shù)進行本地調(diào)用；
6、被調(diào)用者（Server）本地調(diào)用執(zhí)行后將結(jié)果返回給server stub；
7、Server stub將返回值打包編碼成消息，并通過網(wǎng)絡發(fā)送給客戶端；
8、Client stub收到消息后，進行拆包解碼，返回給Client；
9、Client得到本次RPC調(diào)用的最終結(jié)果。
?

gRPC 是一款高性能、開源的 RPC 框架，產(chǎn)自 Google，基于 ProtoBuf 序列化協(xié)議進行開發(fā)，支持多種語言。（ps: rpc是一種協(xié)議，grpc是基于rpc協(xié)議實現(xiàn)的一種框架）

grpc優(yōu)點

• Protocol Buffers 壓縮性高，速度快。
• HTTP 2.0 流傳輸。
• 支持多語言。

grpc缺點

• 可讀性差。
• 對瀏覽器支持有限。
• 外部組件支持較差

ps :?

• RPC主要用于公司內(nèi)部的服務調(diào)用，性能消耗低，傳輸效率高，服務治理方便。
• HTTP主要用于對外的異構(gòu)環(huán)境，瀏覽器接口調(diào)用，APP接口調(diào)用，第三方接口調(diào)用等。

實踐2——異步化服務通信：RPC屬于同步服務通信，若我們需要使用異步化的服務通信可以借助rocketmq或者kafka之類的消息中間件。

Kafka 是一個分布式流式處理平臺。這到底是什么意思呢？

流平臺具有三個關鍵功能：

1、消息隊列：發(fā)布和訂閱消息流，這個功能類似于消息隊列，這也是 Kafka 也被歸類為消息隊列的原因。
2、容錯的持久方式存儲記錄消息流： Kafka 會把消息持久化到磁盤，有效避免了消息丟失的風險·。
3、流式處理平臺： 在消息發(fā)布的時候進行處理，Kafka 提供了一個完整的流式處理類庫。

Kafka 主要有兩大應用場景：

消息隊列 ：建立實時流數(shù)據(jù)管道，以可靠地在系統(tǒng)或應用程序之間獲取數(shù)據(jù)。
數(shù)據(jù)處理： 構(gòu)建實時的流數(shù)據(jù)處理程序來轉(zhuǎn)換或處理數(shù)據(jù)流。

和其他消息隊列相比,Kafka的優(yōu)勢在哪里？

1、極致的性能 ：基于 Scala 和 Java 語言開發(fā)，設計中大量使用了批量處理和異步的思想，最高可以每秒處理千萬級別的消息。
2、生態(tài)系統(tǒng)兼容性無可匹敵 ：Kafka 與周邊生態(tài)系統(tǒng)的兼容性是最好的沒有之一，尤其在大數(shù)據(jù)和流計算領域。

實踐3——服務限流：在服務入口層面加上一個限流器。google的guava rateLimit就可以提供。 在高并發(fā)下一旦服務有問題或異常，將影響大批量流量、大量用戶。?rateLimit是線程安全的，所以在并發(fā)環(huán)境中可以直接使用，無需額外的同步。每個URL使用各自的RateLimiter而不是公用一個，占用的內(nèi)存也不大。

實際使用中，通常先使用tryAcquire()檢測嘗試獲取許可證，如果可行再去執(zhí)行請求； 否則，可以等待一段時間，知道許可證可用，或者適當拒絕。文章來源地址http://www.zghlxwxcb.cn/news/detail-544651.html

到了這里，關于軟考高級系統(tǒng)架構(gòu)設計師(九) 作文模板-微服務架構(gòu)(待繼續(xù)完善)的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！