前言

分布式服務(wù)框架不僅僅包含核心的運(yùn)行時(shí)類庫(kù)，還包括服務(wù)劃分原則、服務(wù)化最佳實(shí)踐、服務(wù)治理、服務(wù)監(jiān)控、服務(wù)開發(fā)框架等，它是一套完整的解決方案，用來(lái)協(xié)助應(yīng)用做服務(wù)化改造，以及指導(dǎo)用戶如何構(gòu)建適合自己業(yè)務(wù)場(chǎng)景的服務(wù)化體系，將服務(wù)化的價(jià)值發(fā)揮到極致。.

基于分布式服務(wù)框架，業(yè)務(wù)終于可以把全部精力都放到應(yīng)用層的邏輯開發(fā)，研發(fā)效率、系統(tǒng)可靠性都得到了極大的提升。目前，華為電信軟件主要解決方案幾乎所有的Java系統(tǒng)都基于分布式服務(wù)框架構(gòu)建，底層的基礎(chǔ)框架實(shí)現(xiàn)了統(tǒng)一。

近年來(lái)，隨著DevOps和以Docker為首的容器技術(shù)的發(fā)展，微服務(wù)架構(gòu)逐漸流行起來(lái)，微服務(wù)架構(gòu)的流行有其必然的歷史原因，它是敏捷開發(fā)、基礎(chǔ)設(shè)施服務(wù)化、DevOps和互聯(lián)網(wǎng)行業(yè)快速發(fā)展的綜合產(chǎn)物。亞馬遜AWS、Netflix 等都是微服務(wù)的成功實(shí)踐者，相信未來(lái)國(guó)內(nèi)越來(lái)越多的大型應(yīng)用也會(huì)演進(jìn)到微服務(wù)架構(gòu)。

華為軟件公司的Java架構(gòu)經(jīng)歷了傳統(tǒng)的MVC垂直架構(gòu)-RPC框架-分布式服務(wù)框架，目前正在向Docker+微服務(wù)方向演進(jìn)，整個(gè)服務(wù)化架構(gòu)的演進(jìn)歷程也是業(yè)界技術(shù)變遷的一個(gè)縮影。

所以說，分布式服務(wù)框架和微服務(wù)，都是成為架構(gòu)師之路的重要基石，不可或缺的技術(shù)，小伙伴們要重視這一塊兒內(nèi)容的學(xué)習(xí)。

今天剛好，就給大家準(zhǔn)備了這兩塊兒的技術(shù)知識(shí)，希望大家能夠喜歡多多轉(zhuǎn)發(fā)讓更多人受益！

咱們將把這兩部分知識(shí)從目錄、內(nèi)容和具體章節(jié)逐一介紹，大家要仔細(xì)研讀！

首先，給大家介紹的第一塊兒內(nèi)容是——分布式服務(wù)框架原理實(shí)踐

1.目錄

2.主要內(nèi)容

第1章，應(yīng)用架構(gòu)演進(jìn)，

隨著業(yè)務(wù)的發(fā)展，應(yīng)用規(guī)模不斷擴(kuò)大，系統(tǒng)內(nèi)部的巨無(wú)霸應(yīng)用越來(lái)越多，常規(guī)的垂直應(yīng)用架構(gòu)已經(jīng)無(wú)法應(yīng)對(duì)復(fù)雜業(yè)務(wù)帶來(lái)的各種挑戰(zhàn)。通過將業(yè)務(wù)公共能力抽象成原子服務(wù)，對(duì)復(fù)雜應(yīng)用進(jìn)行水平拆分和服務(wù)化，實(shí)現(xiàn)服務(wù)消費(fèi)者和提供者的解耦。公共能力抽取和復(fù)用，可以有效降低公共模塊重復(fù)開發(fā)建設(shè)的成本。

傳統(tǒng)垂直架構(gòu)改造的核心就是要對(duì)應(yīng)用做服務(wù)化改造，服務(wù)化改造使用到的核心技術(shù)架構(gòu)就是分布式服務(wù)框架。

本章對(duì)應(yīng)用架構(gòu)的演進(jìn)歷史進(jìn)行剖析，使讀者能夠更清晰和全面地了解應(yīng)用架構(gòu)的歷史演進(jìn)過程以及未來(lái)架構(gòu)的發(fā)展方向。

第2章，分布式服務(wù)框架入門

在一個(gè)不斷發(fā)展的大型應(yīng)用中，新的業(yè)務(wù)需求和功能不斷增加，技術(shù)也在不斷演進(jìn)，不同團(tuán)隊(duì)構(gòu)建的功能子系統(tǒng)采用的技術(shù)架構(gòu)五花八門，子系統(tǒng)之間的開發(fā)、部署和運(yùn)維模式也存在較大差異。如果企業(yè)內(nèi)部沒有統(tǒng)一的服務(wù)框架進(jìn)行技術(shù)層面的拉通，開發(fā)和運(yùn)維效率都將受到很大制約。

傳統(tǒng)垂直架構(gòu)改造的核心就是要對(duì)應(yīng)用進(jìn)行服務(wù)化，服務(wù)化改造使用到的核心技術(shù)就是分布式服務(wù)框架。

第3章，通信框架

單機(jī)版的本地方法調(diào)用變成遠(yuǎn)程服務(wù)調(diào)用之后，一個(gè)高性能的通用通信框架成為分布式服務(wù)框架必不可少的有機(jī)組成部分。

通信框架涉及到Socket通信、多線程編程、協(xié)議棧等相關(guān)知識(shí)，這部分在Java 技術(shù)堆棧中屬于偏難掌握的部分。本章將對(duì)通信框架的原理和設(shè)計(jì)重點(diǎn)進(jìn)行詳細(xì)講解，以期大家可以盡快熟悉通信框架的設(shè)計(jì)要點(diǎn)并在實(shí)際工作中靈活使用。

第4章，序列化與反序列化

服務(wù)提供者和消費(fèi)者通過網(wǎng)絡(luò)進(jìn)行通信，對(duì)象需要進(jìn)行序列化和反序列化，常見的序列化和反序列化方式很多，如何選擇是重點(diǎn)也是難點(diǎn)。

第5章，協(xié)議棧

不同服務(wù)在性能上適用不同協(xié)議進(jìn)行傳輸。比如對(duì)接異構(gòu)第三方服務(wù)時(shí)，通常會(huì)選擇HTTP/Restful 等公有協(xié)議:對(duì)于內(nèi)部不同模塊之間的服務(wù)調(diào)用，往往會(huì)選擇性能較高的二進(jìn)制私有協(xié)議。

第6章，服務(wù)路由

分布式服務(wù)框架.上線運(yùn)行時(shí)都是集群組網(wǎng)，這意味著集群中存在某個(gè)服務(wù)的多實(shí)例部署，消費(fèi)者如何從服務(wù)列表中選擇合適的服務(wù)提供者進(jìn)行調(diào)用，這就涉及到服務(wù)路由。分布式服務(wù)框架要能夠滿足用戶靈活的路由需求。

第7章，集群容錯(cuò)

集群服務(wù)調(diào)用失敗后，服務(wù)框架需要能夠在底層自動(dòng)容錯(cuò)，容錯(cuò)策略很多，分別適用于不同場(chǎng)景。本章將對(duì)集群容錯(cuò)的功能和設(shè)計(jì)進(jìn)行詳細(xì)講解。

第8章，服務(wù)調(diào)用

除了常用的同步服務(wù)調(diào)用之外，分布式服務(wù)框架還需要支持其他幾種形式的服務(wù)調(diào)用，本章將對(duì)這些調(diào)用方式進(jìn)行詳細(xì)講解。

第9章，服務(wù)注冊(cè)中心

對(duì)于服務(wù)提供者，它需要發(fā)布服務(wù)，由于應(yīng)用系統(tǒng)的復(fù)雜性，服務(wù)的數(shù)量、類型不斷膨脹;對(duì)于服務(wù)消費(fèi)者，它最關(guān)心的是如何獲取到它所需要的服務(wù)。對(duì)于服務(wù)提供方和服務(wù)消費(fèi)方來(lái)說，它們還有可能兼具這兩種角色:既需要提供服務(wù)，又需要消費(fèi)服務(wù)。

如何有效地管理服務(wù)訂閱/發(fā)布,避免硬編碼地址信息是分布式服務(wù)框架需要解決的一個(gè)問題。通過將服務(wù)統(tǒng)一管理起來(lái)， 可以有效地優(yōu)化內(nèi)部應(yīng)用對(duì)服務(wù)發(fā)布/使用的流程和管理，服務(wù)注冊(cè)中心就是專門用來(lái)管理服務(wù)訂閱/發(fā)布的配置管理節(jié)點(diǎn)。

第10章，服務(wù)發(fā)布和引用

服務(wù)提供者需要支持通過配置、注解、API 調(diào)用等方式，把本地接口發(fā)布成遠(yuǎn)程服務(wù):對(duì)于消費(fèi)者，可以通過對(duì)等的方式引用遠(yuǎn).程服務(wù)提供者，實(shí)現(xiàn)服務(wù)的發(fā)布和引用

第11章，服務(wù)灰度發(fā)布

灰度發(fā)布是指在黑與白之間，能夠平滑過渡的一種發(fā)布方式。

AB test 就是一種灰度發(fā)布方式:讓一部分用戶繼續(xù)用A,一部分用戶開始用B;如果用戶對(duì)B沒有什么反對(duì)意見，那么逐步擴(kuò)大范圍，把所有用戶都遷移到B上面來(lái)。灰度發(fā)布可以保證整體系統(tǒng)的穩(wěn)定，在初始灰度的時(shí)候就可以發(fā)現(xiàn)、調(diào)整問題，以保證其影響度。

第12章，參數(shù)傳遞

服務(wù)消費(fèi)者和提供者之間進(jìn)行通信時(shí)，除了接口定義的請(qǐng)求參數(shù)，往往還需要攜帶一些額外參數(shù)，例如消息提供者的IP地址、消息調(diào)用鏈的跟蹤ID等;這些參數(shù)不能通過業(yè)務(wù)接口來(lái)進(jìn)行傳遞，

需要底層的分布式服務(wù)框架支持這種參數(shù)傳遞方式。

第13章，服務(wù)多版本

服務(wù)上線之后，隨著業(yè)務(wù)的發(fā)展需要對(duì)功能進(jìn)行變更，或者修復(fù)線上的BUG;服務(wù)升級(jí)之后，往往需要對(duì)服務(wù)采用多版本管理。

服務(wù)多版本管理是分布式服務(wù)框架的重要特性，它涉及服務(wù)的開發(fā)、部署、在線升級(jí)和服務(wù)治理。

第14章，流量控制

當(dāng)資源成為瓶頸時(shí)，服務(wù)框架需要對(duì)消費(fèi)者做限流，啟動(dòng)流控保護(hù)機(jī)制。流量控制有多種策略，比較常用的有:針對(duì)訪問速率的靜態(tài)流控、針對(duì)資源占用的動(dòng)態(tài)流控、針對(duì)消費(fèi)者并發(fā)連接數(shù)的連接控制和針對(duì)并行訪問數(shù)的并發(fā)控制。

在實(shí)踐中，各種流量控制策略需要綜合使用才能起到較好的效果，本章針對(duì)分布式服務(wù)框架的流量控制設(shè)計(jì)原則和實(shí)踐進(jìn)行講解。

第15章，服務(wù)降級(jí)

大促或者業(yè)務(wù)高峰時(shí)，為了保證核心服務(wù)的SLA,往往需要停掉一些不太重要的業(yè)務(wù)，例如商品評(píng)論、論壇或者粉絲積分等。

另外一種場(chǎng)景就是某些服務(wù)因?yàn)槟撤N原因不可用，但是流程不能直接失敗，需要本地Mock服務(wù)端實(shí)現(xiàn)，做流程放通。以圖書閱讀為例，如果用戶登錄余額鑒權(quán)服務(wù)不能正常工作，需要做業(yè)務(wù)放通，記錄消費(fèi)話單，允許用戶繼續(xù)閱讀，而不是返回失敗。

上述兩種場(chǎng)景，都使用到了分布式服務(wù)框架的一個(gè)重要服務(wù)治理功能:服務(wù)降級(jí)。服務(wù)降級(jí)主要包括容錯(cuò)降級(jí)和屏蔽降級(jí)兩種模式，下面我們就兩種服務(wù)降級(jí)的策略和設(shè)計(jì)進(jìn)行講解。

第16章，服務(wù)優(yōu)先級(jí)調(diào)度

當(dāng)系統(tǒng)當(dāng)前資源非常有限時(shí)，為了保證高優(yōu)先級(jí)的服務(wù)能夠正常運(yùn)行，保障服務(wù)SLA，需要降低一些非核心服務(wù)的調(diào)度頻次，釋放部分資源占用，保障系統(tǒng)的整體運(yùn)行平穩(wěn)。

服務(wù)優(yōu)先級(jí)的調(diào)度策略非常多，對(duì)于分布式服務(wù)框架而言，需要能夠支持服務(wù)發(fā)布時(shí)設(shè)置優(yōu)先級(jí)策略，并在資源成為瓶頸時(shí)，按照用戶配置的優(yōu)先級(jí)策略調(diào)度執(zhí)行服務(wù)。

第17章，服務(wù)治理

隨著業(yè)務(wù)的發(fā)展，服務(wù)越來(lái)越多，如何協(xié)調(diào)線上運(yùn)行的各個(gè)服務(wù)，保障服務(wù)的SLA，對(duì)服務(wù)架構(gòu)和運(yùn)維人員是一個(gè)很大的挑戰(zhàn)。

隨著業(yè)務(wù)規(guī)模的不斷擴(kuò)大，小服務(wù)資源浪費(fèi)等問題逐漸顯現(xiàn)，需要能夠基于服務(wù)調(diào)用的性能KPI數(shù)據(jù)進(jìn)行容量管理，合理分配各個(gè)服務(wù)的資源占用，提高機(jī)器的利用率。

線上業(yè)務(wù)發(fā)生故障時(shí)，需要對(duì)故障業(yè)務(wù)做服務(wù)降級(jí)、流量控制、流量遷移等，快速恢復(fù)業(yè)務(wù)。

隨著開發(fā)團(tuán)隊(duì)的不斷擴(kuò)大，服務(wù)的上線越來(lái)越隨意，甚至發(fā)生功能相同、服務(wù)名不同的服務(wù)同時(shí)上線。上線容易下線難，為了規(guī)范服務(wù)的上線和下線，在服務(wù)發(fā)布前，需要走服務(wù)預(yù)發(fā)布流程，由架構(gòu)師或者項(xiàng)目經(jīng)理對(duì)需要上線的服務(wù)做發(fā)布審核，審核通過的才能夠上線。

為了滿足服務(wù)線下管控、保障線上高效運(yùn)行，需要有一個(gè)統(tǒng)一的服務(wù)治理框架對(duì)服務(wù)進(jìn)行統(tǒng)一、有效管控，保障服務(wù)的高效、健康運(yùn)行。

第18章，分布式消息跟蹤

隨著業(yè)務(wù)分布式架構(gòu)的發(fā)展，系統(tǒng)間的系統(tǒng)調(diào)用日趨復(fù)雜，以電商的商品購(gòu)買為例，前臺(tái)界面的購(gòu)買操作涉及到底層上百次服務(wù)調(diào)用，涉及到的中間件包括:

◎分布式服務(wù)框架

◎消息隊(duì)列 .

◎分布式緩存

◎分布式數(shù)據(jù)訪間中間件

◎分布式文件存儲(chǔ)系統(tǒng)

◎分布式日志采集

◎其.....

如果無(wú)法有效清理后端的分布式調(diào)用和依賴關(guān)系，故障定界將會(huì)非常困難。利用分布式消息跟蹤系統(tǒng)可以有效解決服務(wù)化之后系統(tǒng)面臨的運(yùn)維挑戰(zhàn)，提高運(yùn)維效率。

第19章，可靠性設(shè)計(jì)

相對(duì)于傳統(tǒng)的本地Java API調(diào)用，跨進(jìn)程的分布式服務(wù)調(diào)用面臨的故障風(fēng)險(xiǎn)更高。

1)網(wǎng)絡(luò)類故障:鏈路閃斷、讀寫超時(shí)等。

2)序列化和反序列化失敗。

3)畸形碼流。

4)服務(wù)端流控和擁塞保護(hù)導(dǎo)致的服務(wù)調(diào)用失敗。

5)其 他異常.....

對(duì)于應(yīng)用而言，分布式服務(wù)框架需要具備足夠的健壯性，在平臺(tái)底層能夠攔截并向上屏蔽故障，業(yè)務(wù)只需要配置容錯(cuò)策略，即可實(shí)現(xiàn)高可靠性。

第20章，微服務(wù)架構(gòu)

過去十年，SOA ( Service-Oriented Architecture)架構(gòu)得到了廣泛的應(yīng)用，現(xiàn)在，隨著云計(jì)算、移動(dòng)互聯(lián)網(wǎng)、Docker 容器等技術(shù)的快速發(fā)展和應(yīng)用，“微服務(wù)”架構(gòu)(Micro Service Architecture) 這一全新的架構(gòu)風(fēng)格越來(lái)越受到大家的關(guān)注，也有越來(lái)越多的企業(yè)和平臺(tái)服務(wù)提供商在實(shí)踐中嘗試并使用它來(lái)解決具體業(yè)務(wù)問題,微服務(wù)架構(gòu)的流行已經(jīng)成為未來(lái)技術(shù)發(fā)展趨勢(shì)之一。

第21章，服務(wù)化最佳實(shí)踐

在服務(wù)化之前，業(yè)務(wù)通常都是本地API調(diào)用，本地方法調(diào)用性能損耗較小。服務(wù)化之后，服務(wù)提供者和消費(fèi)者之間采用遠(yuǎn)程網(wǎng)絡(luò)通信，增加了額外的性能損耗，業(yè)務(wù)調(diào)用的時(shí)延將增大，同時(shí)由于網(wǎng)絡(luò)閃斷等原因，分布式調(diào)用失敗的風(fēng)險(xiǎn)也增大。如果服務(wù)框架沒有足夠的容錯(cuò)能力，業(yè)務(wù)失敗率將會(huì)大幅提升。

除了性能、可靠性等問題，跨節(jié)點(diǎn)的事務(wù)一致性問題、分布式調(diào)用帶來(lái)的故障定界困難、海量微服務(wù)運(yùn)維成本增加等也是分布式服務(wù)框架必須要解決的難題。本章節(jié)我們將對(duì)服務(wù)化之后面臨的挑戰(zhàn)進(jìn)行分析，并給出解決方案和業(yè)務(wù)最佳實(shí)踐。

其次，給大家介紹第二塊兒內(nèi)容是——微服務(wù)設(shè)計(jì)

1.目錄

2.主要內(nèi)容

第1章微服務(wù)

隨著領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)、持續(xù)交付、按需虛擬化、基礎(chǔ)設(shè)施自動(dòng)化、小型自治團(tuán)隊(duì)、大型集群系統(tǒng)這些實(shí)踐的流行，微服務(wù)也應(yīng)運(yùn)而生。它并不是被發(fā)明出來(lái)的，而是從現(xiàn)實(shí)世界中總結(jié)出來(lái)的一種趨勢(shì)或模式。但是沒有前面提及的這些概念，微服務(wù)也很難出現(xiàn)。在本書接下來(lái)的內(nèi)容中，我會(huì)嘗試把這些概念整合起來(lái)，從而給出一個(gè)涉及如何構(gòu)建、管理和演化微服務(wù)的全景圖。

很多組織發(fā)現(xiàn)細(xì)粒度的微服務(wù)架構(gòu)可以幫助他們更快地交付軟件，并且有更多機(jī)會(huì)嘗試新技術(shù)。微服務(wù)在技術(shù)決策上給了我們極大的自由度，使我們能夠更快地響應(yīng)不可避免的變化。

第2章演化式架構(gòu)師

目前為止可以看到，微服務(wù)給我們提供了很多選擇，因此也需要我們做很多決定。比如應(yīng)該使用多少種不同的技術(shù)，不同的團(tuán)隊(duì)是否應(yīng)使用不同的編程規(guī)范，是應(yīng)該合并多個(gè)服務(wù)還是把一-個(gè)服務(wù)拆成多個(gè)。我們應(yīng)該如何做決定呢?這些架構(gòu)支持在頻繁變換的環(huán)境下以更快的節(jié)奏進(jìn)行變化，因此架構(gòu)師這個(gè)角色也需要做相應(yīng)的改變。本章關(guān)于架構(gòu)師職責(zé)的觀點(diǎn)是我的個(gè)人見解，希望能對(duì)象牙塔中的定義發(fā)起最后的攻擊。

第3章如何建模服務(wù)

現(xiàn)在你已經(jīng)知道什么是微服務(wù)了，希望你對(duì)它的主要優(yōu)點(diǎn)也有所理解。你可能已經(jīng)迫不及待地想要實(shí)現(xiàn)它了，對(duì)嗎?但是從何做起呢?在本章中，我們會(huì)討論如何確定服務(wù)之間的邊界，以期最大化微服務(wù)的好處，避開它的劣勢(shì)。但是，首先我們需要有一個(gè)產(chǎn)品作為討論的載體。

第4章集成

在我看來(lái)，集成是微服務(wù)相關(guān)技術(shù)中最重要的一-個(gè)。做得好的話，你的微服務(wù)可以保持自治性，你也可以獨(dú)立地修改和發(fā)布它們:但做得不好的話會(huì)帶來(lái)災(zāi)難。希望本章能夠幫助你在微服務(wù)之旅中，避免曾經(jīng)在SOA中遇到的那些問題。

第5章分解單塊系統(tǒng)

前面幾章討論了什么是好的服務(wù)以及為什么小服務(wù)能達(dá)到更好的效果，還討論了系統(tǒng)具有可演化性的重要性。但事實(shí)上，可能我們手中已經(jīng)有了很多代碼庫(kù)，而它們無(wú)一例外都沒有遵循上述的模式。如何才能循序漸進(jìn)地把-一個(gè)單塊系統(tǒng)分解開來(lái)呢?

單塊系統(tǒng)的形成非一日之功。開發(fā)人員每天都對(duì)系統(tǒng)添加新功能和新代碼。一段時(shí)間之后，它變成了組織中一個(gè)恐怖而巨大的存在，沒人想去修改它。但別擔(dān)心，它并不是無(wú)可救藥。只要使用了正確的工具，我們就可以手刃這個(gè)怪獸。

第6章部署

部署一個(gè)單塊系統(tǒng)的流程非常簡(jiǎn)單。然而在眾多相互依賴的微服務(wù)中，部署卻是完全不同的情況。如果部署的方法不合適，那么其帶來(lái)的復(fù)雜程度會(huì)讓你很痛苦。本章會(huì)講解一些技巧和技術(shù)，從而幫助我們]在細(xì)粒度的架構(gòu)中更好地部署微服務(wù)。

我會(huì)從持續(xù)集成和持續(xù)交付說起。這些概念與我們下面要討論的主題并不相同，但又有所關(guān)聯(lián)，了 解它們可以幫助我們?cè)诳紤]構(gòu)建什么、如何構(gòu)建以及如何部署時(shí)，做出更好的決定。

第7章測(cè)試

從我開始接觸編程至今，自動(dòng)化測(cè)試的世界日新月異，并且?guī)缀趺總€(gè)月都會(huì)出現(xiàn)新的工具和技術(shù)，不斷推動(dòng)這個(gè)世界向前發(fā)展。不過，如何高效且有效地測(cè)試分布式系統(tǒng)的功能依然是一個(gè)挑戰(zhàn)。本章會(huì)剖析-下測(cè)試細(xì)粒度系統(tǒng)面臨的問題和挑戰(zhàn)，并提出- -些解決方案，幫助大家更有信心地發(fā)布新的功能。

測(cè)試的覆蓋面很廣，即使只討論自動(dòng)化測(cè)試，也需考慮甚多。使用微服務(wù)架構(gòu)以后，測(cè)試的復(fù)雜度進(jìn)-步增加。面對(duì)這樣的挑戰(zhàn)，了解測(cè)試有哪些不同的類型，對(duì)我們來(lái)說便非常重要了。它可以幫助我們實(shí)現(xiàn)盡早交付軟件與保持軟件高質(zhì)量之間的平衡，因?yàn)橛袝r(shí)魚和熊掌是不可兼得的。

第8章監(jiān)控

正如我之前所展示的，將系統(tǒng)拆分成更小的、細(xì)粒度的微服務(wù)會(huì)帶來(lái)很多好處。然而，它也增加了生產(chǎn)系統(tǒng)的監(jiān)控復(fù)雜性。在本章中，我將帶大家看看細(xì)粒度的系統(tǒng)在系統(tǒng)監(jiān)控和定位問題上所面臨的挑戰(zhàn)，同時(shí)還會(huì)介紹一些應(yīng)對(duì)方法，讓魚和熊掌兼得!

設(shè)想一下這樣的場(chǎng)景:一個(gè)安靜的周五下午，團(tuán)隊(duì)期待著早點(diǎn)開溜去酒吧，開始一個(gè)遠(yuǎn)離工作的周末。然而，突然收到一-封郵件:網(wǎng)站工作異常! Twitter 上到處都是關(guān)于貴公司網(wǎng)站出問題的消息，而你的老板在旁邊喋喋不休，一個(gè)安靜的周末就這么沒了。

你需要了解的第一件事情是什么?問題到底出在哪里?

在單塊應(yīng)用的世界里，我們至少要非常清楚該從哪里開始調(diào)查。網(wǎng)站慢?是單塊應(yīng)用的問題。網(wǎng)站有 異常?是單塊應(yīng)用的問題。CPU占用率100% ?還是單塊應(yīng)用的問題。燒焦的氣味?你懂的，單一的故障點(diǎn)會(huì)極大地簡(jiǎn)化對(duì)問題的調(diào)查!

現(xiàn)在，讓我們回到基于微服務(wù)的系統(tǒng)。我們提供給用戶的功能，是由多個(gè)小的服務(wù)組合而成的，其中一些服務(wù)需要集成更多的服務(wù)來(lái)完成功能。這種方法有很多優(yōu)點(diǎn)(這很好，否則這本書豈不是浪費(fèi)時(shí)間? )，但在監(jiān)控的世界里，我們面臨的是一個(gè)更為復(fù)雜的問題。

我們現(xiàn)在有多個(gè)服務(wù)需要監(jiān)控，有多個(gè)日志需要篩選，多個(gè)地方有可能因?yàn)榫W(wǎng)絡(luò)延遲而出現(xiàn)問題。該如何應(yīng)對(duì)呢?我們得好好梳理一下，否則很可能導(dǎo)致混亂，成為一團(tuán)亂麻，而這是周五下午(或在任何時(shí)間! )我們最不想面對(duì)的情況。

這里的答案很簡(jiǎn)單:監(jiān)控小的服務(wù)，然后聚合起來(lái)看整體。我們從最簡(jiǎn)單的系統(tǒng)一-個(gè)節(jié)點(diǎn)，來(lái)展示該如何做。

第9章安全

關(guān)于大型系統(tǒng)的安全漏洞導(dǎo)致數(shù)據(jù)暴露給各種危險(xiǎn)人物的故事，我們已經(jīng)聽說了太多。最近的愛德華●斯諾登泄密事件，更加讓我們意識(shí)到公司持有的用戶信息的價(jià)值，以及保存在為客戶構(gòu)建的系統(tǒng)中的數(shù)據(jù)的價(jià)值。本章將簡(jiǎn)要概述設(shè)計(jì)系統(tǒng)時(shí)，在安全方面應(yīng)該考慮的一些問題。雖然無(wú)法包含安全的方方面面，但會(huì)列出一-些主要的選項(xiàng)給你，為進(jìn)一步研究提供一個(gè)很好的起點(diǎn)。

我們需要考慮，在數(shù)據(jù)從一個(gè)點(diǎn)到另一個(gè)點(diǎn)的傳輸過程中，如何保護(hù)它們，也需要考慮在其他情況下如何進(jìn)行保護(hù)。我們需要考慮底層操作系統(tǒng)及網(wǎng)絡(luò)的安全。有太多需要考慮的點(diǎn)，有太多可以做的事情!那到底需要多安全呢?我們?nèi)绾沃朗裁词亲銐虬踩?

我們還需要考慮人的因素。誰(shuí)在使用我們的系統(tǒng)，他又會(huì)做些什么?而這又與我們的服務(wù)器如何交互有什么關(guān)系?讓我們從這里開始。

第10章康威定律和系統(tǒng)設(shè)計(jì)

到目前為止，本書大部分的內(nèi)容集中在向細(xì)粒度架構(gòu)邁進(jìn)時(shí)所面臨的技術(shù)挑戰(zhàn)。但除此之外，我們也需要考慮組織方面的問題。在這一一章， 我們將了解到忽略公司的組織結(jié)構(gòu)會(huì)帶來(lái)什么樣的危險(xiǎn)。

我們的行業(yè)還很年輕，它似乎在不斷地重塑自己。不過，一些關(guān)鍵定律還是經(jīng)受住了時(shí)間的考驗(yàn)。例如摩爾定律，它表示集成電路上可容納的晶體管數(shù)目每?jī)赡陼?huì)增加一倍。該定律已經(jīng)被證明準(zhǔn)確得驚人(盡管有人預(yù)測(cè)，這種趨勢(shì)已經(jīng)放緩)。還有一條定律，我發(fā)現(xiàn)幾乎普遍適用，在我的日常工作中也更有用，那就是康威定律。

第11章規(guī)模化微服務(wù)

當(dāng)你處理書中的小例子時(shí)，一切似乎都很簡(jiǎn)單，但現(xiàn)實(shí)世界要復(fù)雜得多。當(dāng)我們的微服務(wù)架構(gòu)從剛開始的簡(jiǎn)單變得復(fù)雜后，會(huì)發(fā)生什么呢?當(dāng)我們不得不處理發(fā)生故障的多個(gè)獨(dú)立服務(wù)，或管理數(shù)以百計(jì)的服務(wù)時(shí)，該怎么辦呢?當(dāng)微服務(wù)的數(shù)量比人還多時(shí)，有什么應(yīng)對(duì)的模式嗎?讓我們一起尋找答案吧!

第12章總結(jié)

在前面的章節(jié)我們已經(jīng)討論了相當(dāng)多的內(nèi)容，從微服務(wù)的定義到如何劃分它的邊界，從集成技術(shù)到安全和監(jiān)控。我們甚至還探討了微服務(wù)架構(gòu)下，架構(gòu)師的角色應(yīng)該是什么樣子的。雖然每個(gè)微服務(wù)本身很小，但是它對(duì)架構(gòu)的影響卻很廣很大，所以還是需要學(xué)習(xí)很多東西。在本章，我會(huì)嘗試總結(jié)一些貫穿全書的關(guān)鍵點(diǎn)。

總結(jié)

因?yàn)槲恼聝?nèi)容的限制，小編在這里就不做過多的介紹了，需要這兩部分完整版實(shí)戰(zhàn)技術(shù)文檔的小伙伴，可以移步主頁(yè)獲取！！

你的過去我來(lái)不及參與，但是你的未來(lái)我奉陪到底！

持續(xù)給大家分享技術(shù)知識(shí)，希望大家能夠喜歡！！

感謝大家的支持，感謝頭條官方的支持！