如果面試官詢問微服務架構設計，該如何作答？
為什么要做微服務？
圖片
單體架構達到瓶頸
- 業務復雜度上升，擴展困難，維護費力度上升，牽一發動全身
- 團隊規模擴大，開發沖突增多，開發效率降低，無法兼容多種編程語言
- 性能受到制約，在服務可靠性、吞吐能力、服務部署等方面達到瓶頸
優化架構，更新換代
- 保證技術架構的鮮活度，不與主流脫軌
- 不斷的調整技術建設，支撐內部技術發展
- 更好的架構體系，更有力的支撐業務需求
跟隨潮流，為了微服務而微服務
- 為了緊跟潮流，別人搞我們也要搞
- 為了體驗下微服務架構的魅力
- 為了自己實操一把，掌握微服務技術
微服務的出發點必定是為了解決架構層面遇到的問題，微服務是分而治之的思想。它通過引入更分散的架構思想，從而來解決更復雜的系統問題。所以，微服務并不是所有系統都適用的。在考慮微服務架構的時候，我們得先評估下是否真的需要？從單體到微服務是一個復雜化的過程，如果非必要不微服務。最近，大有微服務合并轉向單體的趨勢。只有我們的系統在業務復雜度層面、系統性能層面、團隊開發協作層面等有了確切的需求，那么微服務確實是不二之選。
微服務到底是什么？
微服務（Microservices）是一種軟件開發架構風格，它將一個復雜的應用程序構建為一系列小型服務的集合，每個服務運行在其獨立的進程中，并通常圍繞特定的業務能力進行構建。這些服務可以通過定義良好的API進行通信，通常是HTTP RESTful API或輕量級的消息傳遞系統。
微服務的核心特點包括：
- 小型化和輕量級：每個服務都相對較小，只關注特定的業務功能。
- 獨立部署：各個微服務可以獨立部署，不需要依賴其他服務。
- 獨立擴展：可以根據需求獨立擴展或收縮特定的服務。
- 技術多樣性：團隊可以根據服務的特定需求選擇最適合的技術棧，包括編程語言和數據存儲等。
- 業務中心化：每個服務都圍繞一項業務能力構建，易于理解和維護。
- 敏捷性：微服務架構提高了開發和部署的速度，使得快速迭代和持續交付成為可能。
- 容錯性：系統中某個服務的故障不會導致整個系統的崩潰，提高了系統的穩定性。
- 去中心化治理：沒有統一的控制中心，服務之間的調用和數據流是去中心化的。
- 去中心化數據管理：每個服務可以有自己的數據庫，實現數據的封裝和隔離。
- 基礎設施自動化：自動化的部署、擴展、監控和故障恢復是微服務架構的關鍵。
我們到底如何進行微服務拆分？
拆分是沒有完全標準的答案和方式，每家公司或者每個團隊拆分的微服務方式可以說是各不相同。但拆分必然有相同的部分，有一些必然需要參考的準則和拆分方式。這些就是我們所需要掌握的，包括面試時候所需要回答出來的點。
微服務拆分原則
- 單一職責原則：每個服務應該有一個清晰定義的職責，并且只負責一個特定的業務功能。
- 業務能力對齊：服務應該圍繞業務能力構建，確保每個服務都是一個可獨立部署和擴展的業務單元。
- 獨立性：每個服務應該是獨立的，擁有自己的代碼庫、數據庫和部署流程。
- 輕量級通信：服務之間的通信應該是輕量級的，避免使用重量級的通信協議。
- 數據隔離：每個服務應該有自己的數據存儲，避免服務之間的數據依賴。
- 去中心化治理：允許每個服務獨立選擇技術棧和框架。
- 容錯性：服務應該能夠容忍其他服務的故障，通常通過斷路器模式實現。
- 敏捷性：服務應該能夠快速迭代和部署，以適應快速變化的業務需求。
- 智能端點和啞管道：服務之間通過簡單的管道通信，而業務邏輯應該封裝在端點中。
- API 網關：使用API網關來提供統一的入口，處理跨服務的請求路由、負載均衡和安全控制。
- 持續集成和持續部署（CI/CD） ：自動化的構建和部署流程對于微服務架構至關重要。
- 監控和日志：實現集中的監控和日志管理，以便于跟蹤和診斷跨服務的問題。
- 團隊自治：每個服務的開發團隊應該有足夠的自治權，以快速響應業務需求。
- 服務發現：實現服務發現機制，以便服務實例可以相互發現并進行通信。
- 斷路器模式：使用斷路器模式來防止級聯故障，并提高系統的穩定性。
- 異步消息傳遞：在可能的情況下，使用異步消息傳遞來解耦服務。
- 版本控制：為服務和API實現版本控制，以支持向后兼容性。
- 安全性：確保每個服務都有適當的安全措施，包括認證和授權。
- 文檔和API管理：為API提供詳細的文檔，并管理API的變更。
- 避免遠程調用：盡量避免遠程服務調用，優先考慮本地服務調用。
- 服務邊界清晰：服務之間的邊界應該清晰定義，避免功能重疊。
- 避免共享服務：避免創建共享服務，因為它們可能導致服務間的耦合。
- 可替換性：設計服務時，應考慮到將來可能的替換或升級。
- 環境一致性：確保開發、測試和生產環境盡可能一致，以減少環境差異導致的問題。
- 配置管理：實現集中的配置管理，以便于跨服務的配置變更。
- 服務契約：定義清晰的服務契約，包括API和數據格式。
- 性能和可伸縮性：在設計服務時，考慮性能和可伸縮性需求。
- 避免過度拆分：避免過度拆分服務，導致過多的服務管理和通信開銷。
微服務拆分方式
- 按業務拆分
這是最常見的拆分方式，根據業務功能的不同將應用程序劃分為不同的服務。每個服務對應一個特定的業務領域，例如用戶管理、訂單處理、庫存管理等。
優點：
服務之間界限清晰，易于管理和維護。
每個服務可以獨立部署和擴展。
缺點：
需要良好的業務領域分析和規劃。
- 按復用度拆分
根據服務的復用程度進行拆分，將那些在多個地方被使用的通用功能（如認證、日志記錄、配置管理）劃分為獨立的服務。
優點：
提高代碼復用性。
便于統一管理和更新通用功能。
缺點：
過度拆分可能導致服務之間的依賴性增加。
- 按冷熱拆分
根據服務的使用頻率以及業務復雜度、需求頻率，將高頻率（熱）服務和低頻率（冷）服務分開部署。熱服務可能需要更多的資源和優化、以及更頻繁的服務發布。
優點：
可以根據服務的實際使用情況優化資源分配。
冷熱分離有助于提高系統整體性能。
有助于保持系統穩定性。
缺點：
需要準確評估服務的使用頻率。
- 按吞吐量拆分
根據服務的吞吐量需求進行拆分，將那些需要高吞吐量處理的服務單獨拆分出來，以便進行專門的優化和擴展。
優點：
可以根據服務的性能需求進行資源分配和優化。
有助于確保關鍵服務的性能。
缺點：
需要對服務的性能特性有深入的了解。
- 按團隊架構拆分
根據團隊的組織結構和開發能力進行服務拆分，每個團隊負責一個或多個服務的開發和維護。
優點：
提高團隊的責任感和開發效率。
便于團隊內部協作和知識共享。
缺點：
可能導致團隊間的溝通和協調成本增加。
微服務與DDD領域驅動設計
微服務與DDD的關系
- 業務邊界的確定：DDD通過戰略設計幫助確定業務邊界，這些邊界可以直接映射到微服務的劃分上。每個限界上下文（Bounded Context）通常對應一個微服務。
- 高內聚低耦合：DDD提倡高內聚的領域模型，這與微服務追求的高內聚、低耦合的服務設計原則相吻合。
- 持續演進：DDD鼓勵通過不斷的迭代來演進領域模型，這與微服務架構中服務的持續集成和持續部署（CI/CD）的理念相符。
- 技術與業務的對齊：DDD通過統一語言（Ubiquitous Language）促進業務專家與開發人員之間的溝通，而微服務架構則通過服務的獨立性支持快速響應業務變化。
- 獨立部署和擴展：DDD中的每個限界上下文都可以獨立部署和擴展，這與微服務的獨立部署和擴展原則一致。
- 領域事件：DDD中的領域事件可以用來觸發微服務間的通信，實現服務間的松耦合。
- 抗腐層：在微服務架構中，DDD的反腐層概念可以幫助維護服務間的清晰界限，確保服務的獨立性和穩定性。
在實踐中，DDD可以幫助團隊更好地理解和建模業務領域，而微服務架構提供了實現這些模型的技術手段。通過DDD的領域模型，可以更容易地識別出微服務的職責和邊界，從而設計出更靈活、可維護和可擴展的系統。
圖片
說白了，DDD誕生了20多年了，之前一直不溫不火是因為DDD很難落地。但隨著微服務的出現，DDD思想與微服務非常契合，2者相輔相成，DDD成為了微服務拆分的指導思想，而微服務有著完善的落地技術方案。DDD通過聚焦業務模型，強調明確清晰的業務邊界，劃分出多個限界下上文，通過定義具體的實體、值對象、聚合根把業務模型分的明明白白，這不就是微服務劃分業務服務最好的軍師嗎？
微服務與其他架構模式的區別
微服務架構與傳統的單體架構、分布式架構和Serverless架構有顯著的不同。以下是微服務架構與其他架構的區別：
微服務架構 vs 單體架構
單體架構：
- 應用程序的所有功能模塊都打包在一起，作為一個單一的單元運行。
- 通常難以維護和更新，因為任何更改都需要重新部署整個應用。
- 技術棧統一，整個應用通常使用相同的編程語言和技術。
微服務架構：
- 應用程序被分解為一系列小型服務，每個服務運行在自己的進程中，并通常圍繞特定的業務功能構建。
- 易于開發和維護，因為每個服務都是獨立的，可以單獨部署、升級和擴展。
- 技術多樣性，不同的服務可以使用不同的編程語言和技術棧。
微服務架構 vs 分布式架構
分布式架構：
- 應用程序被拆分成多個模塊，這些模塊運行在不同的服務器上，并通過網絡通信。是一個更廣泛的概念，已經存在了很長時間，涉及多個計算機或節點協同工作完成復雜任務。
- 指的是系統的組件分布在不同的物理位置，但作為一個整體協同工作。分布式系統不一定涉及服務的拆分，它更側重于組件之間的通信和協作。
微服務架構：
- 雖然微服務架構也是分布式的，但它更側重于服務的獨立性、靈活性和敏捷性。
- 微服務架構是分布式系統架構的一種特殊形式，它專注于更細粒度的服務拆分和獨立部署
微服務架構 vs Serverless架構
Serverless架構：
- 在Serverless架構中，開發者不需要管理服務器，而是將代碼部署到云平臺上，由云平臺負責運行和擴展。
- 通常以函數為單位，按需運行，按實際使用量計費。
微服務架構：
- 微服務通常長期運行，提供持續的服務，而Serverless架構中的函數是事件驅動和短暫運行的。
- 微服務架構可能需要更多的運維工作，因為每個服務都需要獨立管理和部署。
微服務架構 vs Soa架構
微服務架構和SOA（面向服務的架構）都是設計軟件系統的方法，它們在多個方面有相似之處，但也存在一些關鍵的區別：
服務粒度：
- 微服務：通常具有更細的粒度，每個服務都非常專注，以至于可能只有一個單一的職責或功能23。
- SOA：服務粒度較粗，可以包含多個功能，服務組件的大小可以從小型應用程序服務到非常大型的企業服務23。
通信方式：
- 微服務：傾向于使用輕量級的通信機制，如HTTP RESTful API或輕量級的消息傳遞系統12。
- SOA：可能使用更復雜的協議，如WebService BPEL（業務流程執行語言），并且常通過ESB（企業服務總線）進行服務間的通信和集成12。
架構劃分方式：
- 微服務：強調按垂直架構劃分，按照業務能力將系統拆分成獨立的服務，每個服務完成一種特定的功能，服務即產品3。
- SOA：更注重按水平架構劃分，將系統劃分為前端、后端、數據庫和測試等不同的層次
微服務架構 vs Service Mesh
微服務和Service Mesh是云原生架構中的兩個重要概念，它們在軟件架構和部署上有不同的關注點和作用：
微服務（Microservices）：
- 微服務是一種架構風格，它將一個大型復雜軟件應用分解為一組小型、獨立的服務，每個服務運行在自己的進程中，并通常圍繞特定的業務功能構建。
- 微服務之間通過定義良好的API進行通信，通常是HTTP RESTful API或輕量級的消息傳遞系統。
- 微服務架構的優點包括降低系統復雜度、松耦合、跨語言開發、獨立部署等。
Service Mesh（服務網格）：
- Service Mesh是微服務架構中的一個基礎設施層，專門用于處理服務間的通信。它通過使用“sidecar”代理模式，使得服務通信的細節（如發現、負載均衡、故障恢復、度量和監控、安全性等）對應用層透明。
- Service Mesh的典型實現包括Istio、Linkerd、Consul等，它們通常以輕量級代理的形式與應用服務一起部署，而不需要應用代碼的更改。
- Service Mesh解決了微服務架構中的一些挑戰，如服務發現、配置管理、流量控制和故障處理等。
主要區別：
- 關注點：微服務關注的是將應用拆分成獨立部署的小型服務，而Service Mesh關注的是這些服務間的通信和治理。
- 實現：微服務可以通過各種技術棧實現，而Service Mesh通常需要特定的基礎設施支持，如Istio或Linkerd。
- 透明性：Service Mesh通過代理抽象了服務通信的復雜性，對應用層是透明的，而微服務架構中，服務通信的實現細節通常需要開發者自行處理。
- 治理：Service Mesh提供了一套完整的服務治理功能，如流量控制、安全認證、監控等，這些在微服務架構中可能需要額外的工作來實現。
微服務架構是一種將應用分解為獨立服務的方法，而Service Mesh是支持微服務的通信和治理的基礎設施層。Service Mesh可以視為微服務架構的進化，它解決了微服務架構中的一些復雜問題，使得開發者可以更專注于業務邏輯的實現。微服務架構適合于需要高擴展性和靈活性的復雜應用，而Serverless架構適合于無狀態的、事件驅動的應用場景。選擇哪種架構取決于項目的具體需求、團隊的技術能力以及期望的運維復雜度。
微服務中的常見技術實現方案
服務間通信：
- RESTful API：使用HTTP協議和JSON或XML格式進行服務間通信。
- gRPC：一個高性能的RPC框架，使用Protocol Buffers作為接口定義語言。
- Apache Thrift：Facebook開發的一套RPC通信框架，支持多種語言。
- Apache Avro：Apache的一個項目，提供了RPC和數據序列化的功能。
- Apache Dubbo：Alibaba開源的高性能Java RPC框架。
消息隊列：
- Kafka：一個分布式流處理平臺，廣泛用于構建實時數據管道和流式應用。
- RabbitMQ：一個開源的消息代理，也稱為消息隊列。
- Amazon SQS：Amazon提供的一個完全托管的消息隊列服務。
- Google Pub/Sub：Google Cloud提供的事件驅動的異步服務到服務通信。
- Apache Pulsar：一個云原生分布式消息流平臺。
服務注冊與發現：
- Eureka：Netflix開源的服務注冊與發現組件。
- Consul：提供服務發現和配置共享。
- Apache Zookeeper：一個分布式協調服務，可用于服務注冊與發現。
- etcd：一個分布式鍵值存儲，用于配置共享和服務發現。
- Nacos：Alibaba開源的更易于構建云原生應用的動態服務發現、配置管理和服務管理平臺。
配置管理：
- Spring Cloud Config：Spring Cloud的配置管理工具。
- Consul K/V：Consul的鍵值存儲，可用于存儲配置信息。
- Apache ZooKeeper：可以用作分布式配置存儲。
- etcd：除了服務發現，也常用于配置管理。
- Config Server：Spring Cloud Netflix的配置中心組件。
API網關：
- Zuul：Netflix開源的API網關服務。
- Kong：一個云原生API網關，提供API管理、開發平臺和DevOps解決方案。
- Amazon API Gateway：AWS提供的一個完全托管的服務，用于創建、發布、維護、監控和保護API。
- Nginx：一個高性能的HTTP服務器和反向代理，也可以作為API網關使用。
- Traefik：一個開源的邊緣路由器，支持API網關功能。
認證鑒權：
- OAuth 2.0：一個行業標準的協議，用于授權。
- OpenID Connect：基于OAuth 2.0的認證層。
- Apache Shiro：一個強大且易于使用的Java安全框架。
- Spring Security：為Java應用程序提供認證和訪問控制。
- JWT (JSON Web Tokens)：用于在雙方之間安全地傳輸信息。
日志監控：
- ELK Stack（Elasticsearch, Logstash, Kibana）：用于集中日志收集和可視化。
- Prometheus：開源監控和警報工具。
- Grafana：一個跨平臺的開源分析和監控解決方案。
- Fluentd：一個開源的數據收集器，用于統一日志數據收集和消費。
- Graylog：提供數據收集、索引和實時搜索的日志管理平臺。
持續集成與部署：
- Jenkins：一個開源的持續集成工具。
- GitLab CI/CD：GitLab內置的持續集成和持續部署工具。
- CircleCI：提供自動化的持續集成和持續部署服務。
- Travis CI：一個持續集成服務，支持GitHub。
- Spinnaker：一個開源的、多功能的持續交付平臺。
斷路器：
- Hystrix：Netflix開源的斷路器庫，用于容錯。
- Resilience4j：輕量級的容錯庫，靈感來自Hystrix。
- Sentinel：Alibaba開源的輕量級流量控制、熔斷和系統保護開源庫。
- Spring Retry：Spring提供的一個簡單的自動重試機制。
- Polly：一個提供斷路器功能的庫，支持多種語言。
分布式追蹤：
- Zipkin：一個分布式追蹤系統。
- Jaeger：由Uber開發的分布式追蹤系統。
- SkyWalking：一個開源的APM系統，用于分布式系統的追蹤、監控和診斷。
- OpenTelemetry：一個用于觀測分布式系統的工具，提供追蹤、度量和日志。
- AWS X-Ray：AWS提供的一個服務，用于分析和調試分布式Web應用程序。
容器化和編排：
- Docker：用于開發、發布和運行應用程序的容器化平臺。
- Kubernetes：一個開源平臺，用于自動部署、擴展和管理容器化應用程序。
- Apache Mesos：一個集群管理器，提供有效的資源隔離和共享。
- Amazon ECS：AWS提供的容器管理服務。
- Nomad：HashiCorp開發的一個容器編排工具，用于管理容器化和非容器化應用程序的部署。
總結
- 微服務架構現在依舊是架構設計的主流，微服務分而治之的思想永不過時。
- 架構是從簡單到復雜的一個過程，架構設計是為了把復雜變得盡量簡單，所以能用單體就單體，不要盲目微服務，隨之帶來的可能不是微服務的好處，而是成本。
- DDD是微服務拆分的指導思想，它以業務為王，只關心于業務模型本身。
- 微服務拆分按業務是基礎，在業務之上還可以按照業務復雜度、變動頻率、吞吐量、以及團隊情況等進行多維度的拆分。服務的人員分配可參考3個火槍手原則。
- 好的架構一定是邊界清晰、職責明確、規范統一、修少擴多（原先代碼需要修改的少、擴展新增的多）、鏈路明朗、適配靈活、伸縮自如、高內聚低耦合。
圖片
