一、分布式

1、什么是分布式架構

微服務架構是分布式架構，分布式架構不一定是微服務架構

當系統的并發處理能力、存儲能力不足時，我們可能會創建多個web服務(多個tomcat服務器)，多個數據庫服務(主從架構等)，這些服務器通過網絡進行連接，然后協同處理客戶端的并發請求，這樣的系統我們稱之為分布式系統。

2、為什么需要分布式架構

分布式架構可以更好的提高系統的容量、可靠性(避免單點故障)、性能。 同時因為模塊化，系統的可重用性以及并行并發開發的效率也會提高。

當一個系統的業務量越來越大時，我們需要垂直或是水平拆分業務系統，同時為了避免所有業務都部署在一臺機器上時，一旦機器出現故障從而導致整體不可用，就需要將這些業務部署在多臺計算機上，來構建一個分布式架構。

3、分布式架構有哪些優勢？

1. 可以實現更大數據量的存儲。（抖音每天幾十pb的數據）
2. 可以更好提高系統的高可用性。（業務冗余、業務拆分、限流、熔斷）
3. 可以更好提高系統的可重用性。
4. 可以更好提高系統的性能。

4、分布式架構有什么劣勢？

• 復雜性增加：分布式架構的設計和實現相對于單體應用來說更加復雜。開發人員需要考慮到網絡通信、數據一致性、故障處理等方面的問題，這增加了系統的復雜性和開發的難度。
• 性能問題：由于分布式架構將系統拆分成多個服務，服務之間需要通過網絡進行通信，這會引入一定的延遲。同時，分布式系統中的負載均衡和數據分片等機制也會對性能產生一定的影響。
• 一致性難題：在分布式系統中，由于存在多個節點，數據的一致性成為一個復雜的問題。保證數據的一致性需要引入復雜的分布式事務機制，增加了系統的開銷和復雜性。
• 部署和維護成本增加：由于分布式架構涉及多個服務的部署和維護，這增加了部署和維護的成本。同時，對于分布式系統的監控和故障排查也需要更多的工作。
  系統的復雜性增加了故障排查的難度：由于分布式架構的復雜性，當系統出現故障時，排查問題變得更加困難。需要考慮多個服務之間的交互，以及網絡通信等方面的問題。

5、分布式架構有哪些關鍵技術？

• 服務治理

服務治理最大的意義是需要把服務間的依賴關系、服務調用鏈，以及關鍵的服務給梳理出來，并對這些服務進行性能和可用性方面的管理。一般我們所討論的服務拆分、服務注冊、服務發現、服務限流、服務熔斷、降級、服務的鏈路跟蹤，監控等都屬于服務治理的范疇。

• 架構管理

基于服務所形成的架構需要用架構管理、整體架構的生命周期管理，以及對服務的編排、聚合事務處理等服務調度的功能。

• DevOps（開發與運維一體化）

分布式系統可以更為快速的更新服務，但是對于服務的測試和部署都會是挑戰。所以，還需要DevOps的全流程，其中包括環境構建、持續集成、持續部署等、自動化運維。有了DevOps后，我們就可以對服務進行自動伸縮、故障遷移、配置管理、狀態管理等一系列的自動化運維技術了。（AIOps）

• 資源調度管理

應用層的自動化運維需要基礎層的調度支持，也就是云計算IaaS層的計算、存儲、網絡等資源調度、隔離和管理。

• 整體架構監控

如果沒有一個好的監控系統，那么自動化運維和資源調度管理只可能成為一個泡影，因為監控系統是你的眼睛。沒有眼睛、沒有數據，就無法進行高效的運維。所以說，監控是非常重要的部分。這里的監控需要對三層系統（應用層、中間件、基礎層）進行監控。

• 流量控制

6、基于分布式架構如何提高其高性能？

一般面對這樣的問題，首先要從整體維度去思考，要分析問題，例如影響系統性能的因素有哪些？

1. 請求數據的傳輸時間
2. 請求數據的處理時間
3. 響應數據的傳輸時間
4. 響應數據的渲染時間
   當了解影響系統性能的因素以后，此時可以給出一些具體解決方案，例如；
5. 減少數據傳輸時間？（加寬帶，減少數據傳輸量，減少傳輸距離）
6. 提高請求數據的處理速度？（CPU、內存、硬盤、分布式架構，緩存、算法、sql調優，索引的設計、異步）
   3.減少數據在客戶端的渲染時間？（局部更新-Ajax，減少不必要的元素渲染等）
   具體從架構層面進行設計的話可以從如下幾個維度進行思考：

• 應用緩存

為系統添加緩存，可以有效地提高系統的訪問能力。從前端的瀏覽器，到網絡，再到后端的服務，底層的數據庫、文件系統、硬盤和CPU，全都有緩存，這是提高快速訪問能力最有效的手段。

• 負載均衡

負載均衡是做水平擴展的關鍵技術，使用多臺機器來共同分擔一部分流量請求。

• 異步調用

異步系統主要通過消息隊列來對請求做排隊處理，這樣可以把前端的請求的峰值給“削平”了，而后端通過自己能夠處理的速度來處理請求。

• 數據分區和數據鏡像

數據區分是把數據按一定的方式分成多個區（比如通過地理位置），不同的數據區分來分擔不同區的流量。

具體從SQL調優層面如何進行優化呢？

• 獲取執行慢的SQL（通過慢 SQL日志找到執行慢的SQL）
• 獲取影響SQL執行比較慢的原因（通過執行計劃分析SQL執行慢的原因）
• 給出具體SQL的優化方案（例如數據量太大，沒設計索引或沒走索引，SQL結構設計不合理）

7、如何基于架構提高系統的穩定性?

• 服務拆分：分而治之

服務拆分可以更好的實現故障隔離，同時也可以重用服務模塊。

• 服務冗余：有備無患

服務冗余是為了去除單點故障，支持服務的彈性伸縮，以及故障遷移。

• 限流降級：細水長流，斷尾求生

當系統扛不住壓力時，只能通過限流或者功能降級的方式來停掉一部分任務，或是拒絕一部分用戶，以確保整個架構不會掛掉。

• 高可用架構：多機房部署

高可用就是從冗余架構的角度來保障可用性。比如多租戶隔離，災備多活等，總之是wield不出單點故障。

• 高可用運維

指的是DevOps中的CI（持續集成）、CD（持續部署）。一個良好的運維應做了足夠的自動化測試，做相應的灰度發布，以及對線上系統的自動化控制。這樣就可以做到“計劃內”或是“非計劃內”的宕機事件的時長最短。

8、分布式架構有什么難點？

• 異構系統存在很多不標準的問題

構建軟件時使用的編程語言、通訊協議、數據格式、運維標準可能不同，進而導致架構設計的復雜度越來越高。

• 系統架構中的服務依賴問題

傳統的單體應用，一臺機器掛了，整個軟件就垮掉了，分布式架構下也可能出現這樣的問題，因為一個服務可能會依賴另一個服務，某個服務掛掉了，會導致調用鏈上的服務都出現故障。

• 故障發生的概率更大

分布式架構中，服務和機器都會比較多，故障發生的頻率會更大，只是影響面沒有單體應用的影響面大，分布式系統中故障可以被隔離。還有就是分布式架構管理相對于單體架構也更加復雜，沒有優秀的架構管理人員，故障的頻率還是會非常高。

• 多層架構的運維復雜度很大

分布式架構中，我們可以將系統分為四層(基礎層、平臺層、應用層、接入層)

1. 基礎層：包括機器、網絡和存儲設備
2. 平臺層：就是中間件層包括tomcat、MySQL、Redis、RocketMQ類似的軟件。
3. 應用層：就是我們的業務軟件，包括各種業務服務。
4. 接入層：就是接入用戶請求的網關、負載均衡、CDN、DNS等。

二、微服務

1、什么是微服務

微服務是一種軟件架構風格，是一種分布式架構解決方案，簡單點就是將整體大應用，基于業務劃分為更加微小的服務。然后作為獨立的進程進行開發、測試、部署、運行、維護，每個服務都具備獨立的自治能力。

微服務架構具有以下特點：

• 服務拆分：微服務架構將應用程序拆分成多個小型的服務，每個服務都專注于特定的業務功能。這種拆分使得每個服務可以獨立開發、部署和擴展，從而提高了開發效率和系統的靈活性。
• 獨立部署：每個微服務都可以獨立部署，這意味著當一個服務需要更新或修復時，只需要重新部署該服務，而不需要重新部署整個應用程序。這種獨立部署的特性可以減少對整個系統的影響，并提高了系統的可用性。
• 松耦合：微服務架構通過輕量級的通信機制（如RESTful API或消息隊列）來實現服務之間的通信。這種松耦合的通信方式使得每個服務可以獨立演化，而不會對其他服務產生影響。同時，松耦合還使得每個服務可以使用不同的技術棧和編程語言，以滿足不同的需求。
• 可伸縮性：由于每個微服務都是獨立部署的，因此可以根據需求對每個服務進行獨立的擴展。這種可伸縮性使得系統可以根據負載的變化來動態調整資源的分配，從而提高系統的性能和可用性。

2、微服務架構誕生的背景

服務太大了太臃腫，容易產生單點故障，更新迭代也比較慢，所以要拆成若干個小系統，然后進行分而治之。這樣分了之后，可以把每個服務作為一個獨立的開發項目，由小團隊進行快速開發、迭代升級。

3、為什么需要微服務架構

微服務架構是從soa架構模式演變過來的，比SOA架構對服務拆分的粒度更加精細，讓業務界限更加清晰

• SOA 早期均使用了總線模式，這種總線模式是與某種技術棧強綁定的，比如：J2EE。這導致很多企業的遺留系統很難對接，切換時間太長，成本太高，新系統穩定性的收斂也需要一些時間，最終 SOA 看起來很美，但卻成為了企業級奢侈品，中小公司都望而生畏。
• 此外，實施SOA時會遇到很多問題，比如通信協議（例如SOAP）的選擇、第三方中間件如何選擇、服務粒度如何確定等，目前也存在一些關于如何劃分系統的指導性原則，但其中有很多都是錯誤的。SOA并沒有告訴你如何將單體應用劃分成微服務，所以在實施SOA時會遇到很多問題。
• 傳統企業或者很多企業的軟件，大多不止一套系統，都是各個獨立大系統的堆砌。通常存在擴展性差、可靠性不高、維護成本大、重復輪子很多等問題。

對于上述這些問題，可以想到的解決方案有：組件化、服務化。
微服務架構將各個組件或者模塊分散到各個服務中，對整個系統實現解耦。那微服務架構強調的重中之重就是業務系統需要完善的組件化和服務化。

• 組件化：將一個大系統，按照一定的業務或者技術維度關注形式，拆分成獨立的組件。目的是為了分而治之，為了可重用，為了減少耦合度。比如按照技術維度：搜索組件、緩存組件；按照業務維度：用戶中心、支付中心等
• 服務化：是一種以服務為中心的解決方案：服務注冊、服務發布、服務調用、服務監控、服務負載均衡等。核心就是不同服務之間的通信。服務化之前：代碼重復、可維護性低、DB 訪問耦合等。服務化后的好處：調用簡單、代碼復用、業務隔離、數據庫解耦等

4、微服務架構存在的問題

服務注冊與發現：
微服務之間相互調用完成整體業務功能，需要考慮如何在眾多微服務中找到正確的目標服務地址。 這就是所謂「服務發現」功能，常用的做法是：

• 服務提供方啟動的時候把自己的地址上報給「服務注冊中心」，這就是「服務注冊」。
• 服務調用方「訂閱」服務變更「通知」，動態的接收服務注冊中心推送的服務地址列表，以后想找哪個服務直接發給他就可以。
• 分布式服務注冊與發現（eureka、consul、zookeeper、Nacos）
• 分布式事務解決方案（rabbitmq、rocketmq事務消息、lnc（淘汰）、setata）最終一致性概念
• 分布式任務調度平臺（XXL-Job、AlibabaCloud Scheduler、elastic-job）

運維成本：
微服務將系統分成多個獨立的部分，每個部分都是可以獨立部署的業務單元。這就意味著，在微服務架構下，隨著服務數量的增多，每個服務都需要獨立的配置、部署、監控、日志收集等，因此成本呈指數級增長。

• 這就需要我們有一套完備的服務監控體系，包括拓撲關系、監控（Metrics）、日志監控（Logging）、調用追蹤（Trace）、告警通知、健康檢查等，防患于未然。
• 分布式日志采集系統elk+kafka
• 分布式服務追蹤與調用鏈系統Zipkin

部署自動化：
對于微服務架構而言，每個服務都是一個獨立可部署的業務單元，每個服務的修改都需要獨立部署。如何有效地構建自動化部署流水線，降低部署成本、提高部署頻率，是微服務架構下需要面臨的一個挑戰。

• 分布式服務配置中心（springcloud config/nacos/disconfig/攜程阿波羅）

服務容錯：
生產環境復雜多變，服務運行過程中不可避免的發生各種故障（宕機、過載等等），需要引入「熔斷、隔離、限流和降級、超時機制」等「服務容錯」機制來保證服務持續可用性。
微服務是拆分成多個服務進行部署，服務間的通信都是通過網絡，此時的性能會受影響。同時可靠性也會受影響。數據一致性也需要嚴格控制，其成本也比單塊系統高。
服務治理：
由于微服務架構是把系統拆分為若干個可獨立部署的服務，所以需要：

• 進行服務間的依賴測試：在服務數量較多的情況下，如何有效地保證服務之間能有效按照接口的約定正常工作，成為微服務實施過程中必須面臨的巨大挑戰。
• 隨著微服務個數的增多，如何清晰有效地展示服務之間的依賴關系，成為了一個挑戰。

服務安全：
有些服務的敏感數據存在安全問題，「服務安全」就是對敏感服務采用安全鑒權機制，對服務的訪問需要進行相應的身份驗證和授權，防止數據泄露的風險。

DevOps 與組織結構：
傳統單塊架構中，團隊通常是按技能劃分，如開發部、測試部、運維部，并通過項目的方式協作，完成系統交付。而在微服務架構的實施過程中，在組織或者團隊層面，如何傳遞 DevOps 文化的價值，讓團隊理解 DevOps 文化的價值，并構建全功能團隊，也是一個不小的挑戰。

• 微服務不僅表現出一種架構模型，同樣也表現出一種組織模型。
• 這種新型的組織模型意味著開發人員和運維的角色發生了變化，開發者將承擔起服務整個生命周期的責任，包括部署和監控，而運維也越來越多地表現出一種顧問式的角色，盡早考慮服務如何部署。
• 因此，如何在微服務的實施中，按需調整組織架構，構建全功能的團隊，是一個不小的挑戰。

5、微服務架構的優點

• 技術異構性：
  不同服務內部的開發技術可以不一致，你可以用java來開發helloworld服務A，用golang來開發helloworld服務B。
  為不同的服務選擇最適合該服務的技術，系統中不同部分也可以使用不同的存儲技術，比如A服務可以選擇redis存儲，B服務你可以選擇用MySQL存儲，這都是允許的。
• 隔離性：
  一個服務不可用不會導致另一個服務也癱瘓，因為各個服務是相互獨立和自治的系統。
  這在單體應用程序中是做不到的，單體應用程序中某個模塊癱瘓，必將導致整個系統不可用，當然，單體程序也可以在不同機器上部署同樣的程序來實現備份，不過，同樣存在資源浪費問題。
• 可擴展性：
  可以只對那些影響性能的服務做擴展升級，這樣對癥下藥的效果是很好的。
  龐大的單體服務如果出現性能瓶頸只能對軟件整體進行擴展，可能真正影響性能的只是其中一個很小的模塊，我們也不得不付出升級整個應用的代價，這在微服務架構中得到了改善。
• 簡化部署：
  在微服務架構中，各個服務的部署是獨立的，如果真出了問題也只是影響單個服務，可以快速回滾版本解決。
  如果你的服務是一個超大的單體服務，有幾百萬行代碼，即使修改了幾行代碼也要重新編譯整個應用，這顯然是非常繁瑣的，而且軟件變更帶來的不確定性非常高，軟件部署的影響也非常大。
• 易優化：
  微服務架構中單個服務的代碼量不會很大，這樣當你需要重構或者優化這部分服務的時候，就會容易很多，畢竟，代碼量越少意味著代碼改動帶來的影響越可控。

6、常見的微服務架構

Dubbo
Dubbo是阿里巴巴開源的基于 Java 的高性能 RPC（一種遠程調用） 分布式服務框架（SOA），致力于提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。
Dubbo 提供的基礎能力包括： 服務發現、流式通信、負載均衡、流量治理等等。
提供的通信模型： 同步的 Request-Response （默認）、消費端異步請求、提供端異步執行、消費端請求流、提供端響應流、雙向流式通信。
Dubbo 提供的是 Client-Based 的服務發現機制，使用者可以有多種方式啟用服務發現：

• 使用獨立的注冊中心組件，如 Nacos、Zookeeper、Consul、Etcd 等。
• 將服務的組織與注冊交給底層容器平臺，如 Kubernetes。

部署架構： 為了在分布式環境下實現各個微服務組件間的協作， Dubbo 定義了一些中心化組件。

• 注冊中心
• 配置中心
• 元數據中心
  

Tars
騰訊內部使用的微服務架構 TAF（Total Application Framework）多年的實踐成果總結而成的開源項目。
僅支持 C++ 語言，目前在騰訊內部應用也非常廣泛。2017 年對外開源，僅支持 C++ 語言。
gRPC
是Google開發的高性能、通用的開源RPC框架，其由Google主要面向移動應用開發并基于HTTP/2協議標準而設計，基于ProtoBuf(Protocol Buffers)序列化協議開發。
本身它不是分布式的，所以要實現上面的框架的功能需要進一步的開發。2015 年對外開源的跨語言 RPC 框架，支持多種語言。

thrift
最初是由 Facebook 開發的內部系統跨語言的高性能 RPC 框架，2007 年貢獻給了 Apache 基金，成為 Apache 開源項目之一， 跟 gRPC 一樣，Thrift 也有一套自己的接口定義語言 IDL，可以通過代碼生成器，生成各種編程語言的 Client 端和 Server 端的 SDK 代碼，支持多種語言。

微服務框架與RPC

• 什么是RPC？ RPC (Remote Procedure
  Call）遠程過程調用是一個計算機通信協議。我們一般的程序調用是本地程序內部的調用，RPC允許你像調用本地函數一樣去調用另一個程序的函數，這中間會涉及網絡通信和進程間通信，但你無需知道實現細節，RPC框架為你屏蔽了底層實現。

• RPC是一種服務器-客戶端（Client/Server）模式，經典實現是一個通過發送請求-接受回應進行信息交互的系統。

• 兩者關系： 微服務框架一般都包含了RPC的實現和一系列「服務治理」能力，是一套軟件開發框架。我們可以基于這個框架之上實現自己的微服務，方便的利用微服務框架提供的「服務治理」能力和RPC能力，所以微服務框架也被有些人稱作RPC框架。

三、分布式架構和微服務架構的區別

分布式架構和微服務架構是兩種不同的架構模式，它們在設計和實現上有一些明顯的區別。下面是它們之間的對比：

	分布式架構	微服務架構
定義	分布式架構是將一個大型系統劃分為多個獨立的模塊，這些模塊可以在不同的服務器上運行，通過網絡進行通信。	微服務架構是一種將應用程序劃分為一組小型、獨立的服務的架構，每個服務都可以獨立部署、擴展和維護。
系統復雜性	分布式架構通常需要更多的協調和管理，因為不同的模塊需要通過網絡進行通信和協調。	微服務架構通過將系統拆分為小型服務，降低了系統的復雜性，每個服務可以獨立開發和部署。
擴展性	分布式架構通常需要在整個系統上進行擴展，當系統的負載增加時，需要增加整個系統的資源。	微服務架構允許對系統的不同服務進行獨立的擴展，當某個服務的負載增加時，只需增加該服務的資源。
可維護性	分布式架構的模塊間的依賴關系較強，當一個模塊發生變化時，可能會影響到其他模塊，導致維護困難。	微服務架構的每個服務都是獨立的，當一個服務發生變化時，只需關注該服務的維護，不會影響其他服務。
部署	分布式架構需要將整個系統一起部署，當一個模塊發生變化時，需要重新部署整個系統。	微服務架構允許每個服務獨立部署，當某個服務發生變化時，只需重新部署該服務。