### 微服務的九大特性
> 1. **服務組件化**
> 2. **按業務組織團隊**
> 3. **做“產品”的態度**
> 4. **智能端點與啞管道**
> 5. **去中心化治理**
> 6. **去中心化數據管理**
> 7. **基礎設施自動化**
> 8. **容錯設計**
> 9. **演進式設計**
* **服務組件化**
組件,是一個可以獨立更換和升級的單元。就像PC中的CPU、內存、顯卡、硬盤一樣,獨立且可以更換升級而不影響其他單元。在“微服務”架構中,需要我們對服務進行組件化分解。服務,是一種進程外的組件,它通過http等通信協議進行協作,而不是傳統組件以嵌入的方式協同工作。服務都獨立開發、部署,可以有效的避免一個服務的修改引起整個系統的重新部署
微服務架構中將組件定義為可被獨立替換和升級的軟件單元,在應用架構設計中通過將整體應用切分成可獨立部署及升級的微服務方式進行組件化設計
* **按業務組織團隊**
微服務架構采取以業務能力為出發點組織服務的策略,因此微服務團隊的組織結構必須是跨功能的(如:既管應用,也管數據庫)、強搭配的DevOps開發運維一體化團隊,通常這些團隊不會太大;
當我們開始決定如何劃分“微服務”時,通常也意味著我們要開始對團隊進行重新規劃與組織。按以往的方式,我們往往會以技術的層面去劃分多個不同的團隊,比如:DBA團隊、運維團隊、后端團隊、前端團隊、設計師團隊等等。若我們繼續按這種方式組織團隊來實施“微服務”架構開發時,當有一個有問題需要更改,可能是一個非常簡單的變動,比如:對人物描述增加一個字段,這就需要從數據存儲開始考慮一直到設計和前端,雖然大家的修改都非常小,但這會引起跨團隊的時間和預算審批。
在實施“微服務”架構時,需要采用不同的團隊分割方法。由于每一個微服務都是針對特定業務的寬棧或是全棧實現,既要負責數據的持久化存儲,又要負責用戶的接口定義等各種跨專業領域的職能。因此,面對大型項目時候,對于微服務團隊拆分更加建議按業務線的方式進行拆分,一方面可以有效減少服務內部修改所產生的內耗;另一方面,團隊邊界可以變得更為清晰
* **做“產品”的態度**
傳統的應用模式是一個團隊以項目模式開發完整的應用,開發完成后就交付給運維團隊負責維護;微服務架構則倡導一個團隊應該如開發產品般負責一個“微服務”完整的生命周期,倡導“誰開發,誰運營”的開發運維一體化方法
* **智能端點與啞管道**
微服務架構主張將組件間通訊的相關業務邏輯/智能放在組件端點側而非放在通訊組件中,通訊機制或組件應該盡量簡單及松耦合。RESTful HTTP協議和僅提供消息路由功能的輕量級異步機制是微服務架構中最常用的通訊機制
在“微服務”架構中,通常會使用這兩個服務調用方式:
* 第一種,使用HTTP協議的RESTful API或輕量級的消息發送協議,來實現信息傳遞與服務調用的觸發。
* 第二種,通過在輕量級消息總線上傳遞消息,類似RabbitMQ等一些提供可靠異步交換的結構
> 在極度強調性能的情況下,有些團隊會使用二進制的消息發送協議,例如:protobuf。即使是這樣,這些系統仍然會呈現出“智能端點和啞管道”的特點,為了在易讀性與高效性之間取得平衡。當然大多數Web應用或企業系統并不需要作出在這兩者間做出選擇,能夠獲得易讀性就已經是一個極大的勝利了。 ——Martin Fowler
* **去中心化治理**
整體式應用往往傾向于采用單一技術平臺,微服務架構則鼓勵使用合適的工具完成各自的任務,每個微服務可以考慮選用最佳工具完成\(如不同的編程語言\)。微服務的技術標準傾向于尋找其他開發者已成功驗證解決類似問題的技術
* **去中心化數據管理**
微服務架構倡導采用多樣性持久化\(PolyglotPersistence\)的方法,讓每個微服務管理其自有數據庫,并允許不同微服務采用不同的數據持久化技術;
數據管理的去中心化可以讓數據管理更加細致化,通過采用更合適的技術來讓數據存儲和性能達到最優。但是,由于數據存儲于不同的數據庫實例中后,數據一致性也成為“微服務”架構中急需解決的問題之一。分布式事務的實現,本身難度就非常大,所以在“微服務”架構中,我們更強調在各服務之間進行“無事務”的調用,而對于數據一致性,只要求數據在最后的處理狀態是一致的效果;若在過程中發現錯誤,通過補償機制來進行處理,使得錯誤數據能夠達到最終的一致性
* **基礎設施自動化**
云化及自動化部署等技術極大地降低了微服務構建、部署和運維的難度,通過應用持續集成和持續交付等方法有助于達到加速推出市場的目的;
在“微服務”架構中,請務必從一開始就構建起“持續交付”平臺來支撐整個實施過程,該平臺需要兩大內容,不可或缺:
1. 自動化測試:每次部署前的強心劑,盡可能的獲得對正在運行軟件的信心;
2. 自動化部署:解放繁瑣枯燥的重復操作以及對多環境的配置管理;
3. **容錯設計**
微服務架構所帶來的一個后果是必須考慮每個服務的失敗容錯機制。因此,微服務非常重視建立架構及業務相關指標的實時監控和日志機制;
在單體應用中,一般不存在單個組件故障而其他還在運行的情況,通常是一掛全掛。而在“微服務”架構中,由于服務都運行在獨立的進程中,所以是存在部分服務出現故障,而其他服務都正常運行的情況,比如:當正常運作的服務B調用到故障服務A時,因故障服務A沒有返回,線程掛起開始等待,直到超時才能釋放,而此時若觸發服務B調用服務A的請求來自服務C,而服務C頻繁調用服務B時,由于其依賴服務A,大量線程被掛起等待,最后導致服務A也不能正常服務,這時就會出現故障的蔓延。
所以,在“微服務”架構中,快速的檢測出故障源并盡可能的自動恢復服務是必須要被設計和考慮的。通常,我們都希望在每個服務中實現監控和日志記錄的組件,比如:服務狀態、斷路器狀態、吞吐量、網絡延遲等關鍵數據的儀表盤等
* **演進式設計**
微服務應用更注重快速更新,因此系統的計會隨時間不斷變化及演進。微服務的設計受業務功能的生命周期等因素影響。如某應用是整體式應用,但逐漸朝微應用架構方向演進,整體式應用仍是核心,但新功能將使用應用所提供的API構建。再如在某微服務應用中,可替代性模塊化設計的基本原則,在實施后發現某兩個微服務經常必須同時更新,則這很可能意味著應將其合并為一個微服務
- 概述
- CAP理論
- BASE理論
- ACID
- 分布式系統相關技術
- 主流數據庫連接池
- 基礎
- 系統單點
- 負載均衡
- HTTP重定向負載均衡
- DNS域名解析負載均衡
- 反向代理負載均衡
- IP負載均衡
- 數據鏈路層負載均衡
- 負載均衡算法
- 輪詢法(Round Robin)
- 加權輪詢(Weight Round Robin)
- 隨機算法(Random)
- 源地址Hash算法
- 加權隨機法(Weight Random)
- 最小連接數法(Least Connections)
- 接入層負載均衡
- 軟件架構
- 性能
- 性能測試指標
- 響應時間
- 并發數
- 吞吐量
- 性能計數器
- 性能測試方法
- 性能測試報告
- 性能優化
- Web前端性能優化
- 應用服務器性能優化
- 可用性
- 服務降級
- 伸縮性
- 擴展性
- 事件驅動架構
- 安全性
- 信息加密技術
- 分布式系統概述
- 自動化
- 分布式唯一ID
- 冪等設計
- 分布式鎖
- 腦裂
- 一致性原理
- Paxos
- Zab
- Raft
- 分布式遠程服務調用
- RMI
- Spring RMI
- WebService
- SOA服務架構
- 微服務架構
- 微服務的九大特性
- 服務注冊和發現
- 解決方案及組件
- 分布式網關
- 注冊中心
- Zookeeper
- ZNode
- Watch接口
- 持久節點-配置中心實現原理
- 臨時節點-注冊中心
- Zookeeper選舉
- Zookeeper角色
- ZooKeeper工作原理
- 選主流程
- 同步流程
- Leader工作流程
- Follower工作流程
- 常見限流算法
- 計數器算法
- 漏桶算法
- 令牌桶算法
- 滑動窗口
- 計數器&滑動窗口
- 斷路器
- 大流量高并發高可用
- 高可用
- 高并發/大流量
- 分布式緩存系統
- 基本概念
- 緩存命中率
- 緩存最大元素
- 緩存回收策略
- 回收算法
- 緩存穿透與緩存雪崩
- CDN緩存
- 緩存分類
- memcached
- 客戶端路由原理
- 內存管理機制
- Redis
- Redis數據模型
- redisObject/Redis type/Redis encoding
- 命令的類型檢查和多態
- skiplist跳躍表
- 為什么使用跳躍表
- redis-內存管理機制
- Redis淘汰策略
- Redis持久化策略
- Redis并發競爭
- redis主從復制
- Redis集群實現方案
- Redis Cluster
- redis事務
- Redis-Sentinel
- Redis適用場景
- Redis客戶端
- redis rehash原理
- dict數據結構
- 觸發rehash的條件
- 漸進式rehash
- 漸進式rehash過程
- Redis多線程版本
- 緩存實際應用
- 堆緩存-Guava Cache
- 主要參數
- Caffeine
- Spring注解緩存
- 分布式存儲
- Database
- AUTOCOMMIT
- 臟讀&幻讀&不可重復讀
- 子查詢
- 連接
- 內連接
- 自連接
- 自然連接
- 外連接
- 組合查詢
- 隔離級別
- 數據庫范式
- 索引實現機制
- 數據庫拆分
- 表分區
- 分庫
- 分表
- MySQL
- MySQL基礎架構
- 鎖分類
- 排它鎖&獨占鎖
- 共享鎖
- 間隙鎖
- 表級鎖
- 存儲引擎
- 磁盤IO
- 磁盤結構圖
- 磁盤數據讀寫原理
- MySQL索引原理
- B+樹索引
- 局部性原理
- 索引數據結構
- 聯合索引
- 最左前綴匹配原則
- 建索引的幾大原則
- 數據文件和索引文件
- 執行計劃explain
- 常見問題
- 數據頁
- MYSQL單表存儲量計算
- 回表
- 索引覆蓋
- 索引下推
- 頁分裂和頁合并
- InnoDB
- innodb索引
- Innodb引擎的底層實現
- MyISAM
- MyISAM引擎的底層實現
- MVCC
- Next-Key Locks
- MySQL索引類型
- MYSQL復制
- 主從復制
- 讀寫分離
- MySQL Dual-Master
- 分庫分表實現方案
- MySQL事務實現原理
- MYSQL調優
- 性能優化
- HBase
- 不停機分庫分表遷移
- RDBMS&NoSQL
- 分布式事務
- 協議或事務模型
- X/Open XA協議
- 分布式事務編程接口規范JTA
- TCC模型
- 解決方案
- 兩階段提交2PC
- 三階段提交3PC
- Seata
- 分布式事務Seata產品模塊
- AT模式
- TCC模式
- Saga模式
- XA模式
- 基于消息中間件的最終一致性事務方案
- 消息隊列
- AMQP
- JMS
- ActiveMQ
- RabbitMQ
- RocketMQ
- RocketMQ基本概念
- 主要特性
- 分區順序消息
- 全局順序消息
- 消息可靠性
- 定時消息
- 消息重試
- 死信隊列
- 分布式事務消息
- RocketMQ架構
- Producer
- Consumer
- NameServer
- Broker
- RocketMQ設計
- 消息存儲
- 頁緩存與內存映射
- 消息刷盤
- 通信機制
- console控制臺
- RocketMQ部署架構
- Kafka
- Pulsar
- MQ消息重復消費與丟失
- 主流消息隊列比較
- 分布式調度系統
- 分布式搜索
- 分布式計算
- 架構案例
- 秒殺業務
- 秒殺整體架構
- 常見的監控系統
- 小米手機搶購秒殺方案
- 架構師領導藝術
- 架構師箴言
- 技術leader核心職責
- WEB服務器
- Servlet
- Servlet實現
- Servlet生命周期
- Servlet容器工作模式
- Servlet工作原理
- servlet線程安全
- CGI&FastCGI
- CGI
- FastCGI
- FastCGI與CGI特點
- CGI與Servlet比較
- HTTP Server
- Nginx
- Apache
- Nginx與Apache比較
- Application Server
- Tomcat
- Tomcat總體架構
- Connector
- 連接器核心功能
- ProtocolHandler
- EndPoint
- Processor
- Adapter
- Container
- 請求定位Servlet的過程
- Lifecycle生命周期
- Tomcat模塊設計
- Tomcat實例
- Tomcat運行原理
- spring & servlet
- Tomcat啟動流程
- Tomcat支持的I/O模型
- Tomcat應用層協議
- Tomcat類加載機制
- Tomcat類加載器
- Tomcat類加載器層次
- Apache+Tomcat
- 序列化
- XML&JSON
- JSON
- JAVA原生序列化
- hessian
- 常見中間件
- Canal
- Databus
- ELK日志套件
- 數據庫連接池
- spring狀態機
- 常見解決方案
- 二維碼掃碼登錄原理
- 前沿技術
- Saas服務
- 服務網格(Service Mesh)
- 云原生
- 常見面試問題
- Redis持久化的幾種方式
- Redis的緩存失效策略
- 附錄
- 二將軍問題
- 常見問題定位步驟
- 如何快速熟悉新系統
- 制定技術方案套路
- NUMA陷阱