後端架構師技術圖譜

禹發表於2020-01-15
後端架構

摘自 後端架構師技術圖譜 ，希望為這麼好的文章增加曝光度

《後端架構師技術圖譜》

推薦: 《Java技術書籍大全》 - awesome-java-books

從初級開發者到資深架構師，看這些書就夠了

（Toc generated by simple-php-github-toc ）

資料結構

佇列

集合

連結串列、陣列

字典、關聯陣列

棧

樹

二叉樹

每個節點最多有兩個葉子節點。

完全二叉樹

  • 《完全二叉樹》
    • 葉節點只能出現在最下層和次下層，並且最下面一層的結點都集中在該層最左邊的若干位置的二叉樹。

平衡二叉樹

左右兩個子樹的高度差的絕對值不超過1，並且左右兩個子樹都是一棵平衡二叉樹。

二叉查詢樹（BST）

二叉查詢樹（Binary Search Tree），也稱有序二叉樹（ordered binary tree）,排序二叉樹（sorted binary tree）。

紅黑樹

B，B+，B*樹

MySQL是基於B+樹聚集索引組織表

LSM 樹

LSM（Log-Structured Merge-Trees）和 B+ 樹相比，是犧牲了部分讀的效能來換取寫的效能(通過批量寫入)，實現讀寫之間的平衡。 Hbase、LevelDB、Tair（Long DB）、nessDB 採用 LSM 樹的結構。LSM可以快速建立索引。

  • 《LSM樹 VS B+樹》

    • B+ 樹讀效能好，但由於需要有序結構，當key比較分散時，磁碟尋道頻繁，造成寫效能較差。
    • LSM 是將一個大樹拆分成N棵小樹，先寫到記憶體（無尋道問題，效能高），在記憶體中構建一顆有序小樹（有序樹），隨著小樹越來越大，記憶體的小樹會flush到磁碟上。當讀時，由於不知道資料在哪棵小樹上，因此必須遍歷（二分查詢）所有的小樹，但在每顆小樹內部資料是有序的。

  • 《LSM樹（Log-Structured Merge Tree）儲存引擎》

    • 極端的說，基於LSM樹實現的HBase的寫效能比MySQL高了一個數量級，讀效能低了一個數量級。
    • 優化方式：Bloom filter 替代二分查詢；compact 小數位大樹，提高查詢效能。
    • Hbase 中，記憶體中達到一定閾值後，整體flush到磁碟上、形成一個檔案（B+數），HDFS不支援update操作，所以Hbase做整體flush而不是merge update。flush到磁碟上的小樹，定期會合併成一個大樹。

BitSet

經常用於大規模資料的排重檢查。

常用演算法

排序、查詢演算法

選擇排序

氣泡排序

插入排序

快速排序

歸併排序

希爾排序

TODO

堆排序

計數排序

桶排序

基數排序

按照個位、十位、百位、...依次來排。

二分查詢

Java 中的排序工具

布隆過濾器

常用於大資料的排重，比如email，url 等。 核心原理：將每條資料通過計算產生一個指紋（一個位元組或多個位元組，但一定比原始資料要少很多），其中每一位都是通過隨機計算獲得，在將指紋對映到一個大的按位儲存的空間中。注意：會有一定的錯誤率。 優點：空間和時間效率都很高。 缺點：隨著存入的元素數量增加，誤算率隨之增加。

字串比較

KMP 演算法

KMP：Knuth-Morris-Pratt演算法（簡稱KMP） 核心原理是利用一個“部分匹配表”，跳過已經匹配過的元素。

深度優先、廣度優先

貪心演算法

回溯演算法

剪枝演算法

動態規劃

樸素貝葉斯

推薦演算法

最小生成樹演算法

最短路徑演算法

併發

Java 併發

多執行緒

執行緒安全

一致性、事務

事務 ACID 特性

事務的隔離級別

  • 未提交讀：一個事務可以讀取另一個未提交的資料，容易出現髒讀的情況。

  • 讀提交：一個事務等另外一個事務提交之後才可以讀取資料，但會出現不可重複讀的情況（多次讀取的資料不一致），讀取過程中出現UPDATE操作，會多。（大多數資料庫預設級別是RC，比如SQL Server，Oracle），讀取的時候不可以修改。

  • 可重複讀： 同一個事務裡確保每次讀取的時候，獲得的是同樣的資料，但不保障原始資料被其他事務更新（幻讀），Mysql InnoDB 就是這個級別。

  • 序列化：所有事物序列處理（犧牲了效率）

  • 《理解事務的4種隔離級別》

  • 資料庫事務的四大特性及事務隔離級別

  • 《MySQL的InnoDB的幻讀問題 》

    • 幻讀的例子非常清楚。
    • 通過 SELECT ... FOR UPDATE 解決。

  • 《一篇文章帶你讀懂MySQL和InnoDB》

    • 圖解髒讀、不可重複讀、幻讀問題。

MVCC

鎖

Java中的鎖和同步類

公平鎖 & 非公平鎖

公平鎖的作用就是嚴格按照執行緒啟動的順序來執行的，不允許其他執行緒插隊執行的；而非公平鎖是允許插隊的。

悲觀鎖

悲觀鎖如果使用不當（鎖的條數過多），會引起服務大面積等待。推薦優先使用樂觀鎖+重試。

樂觀鎖 & CAS

ABA 問題

由於高併發，在CAS下，更新後可能此A非彼A。通過版本號可以解決，類似於上文Mysql 中提到的的樂觀鎖。

CopyOnWrite容器

可以對CopyOnWrite容器進行併發的讀，而不需要加鎖。CopyOnWrite併發容器用於讀多寫少的併發場景。比如白名單，黑名單，商品類目的訪問和更新場景，不適合需要資料強一致性的場景。

RingBuffer

可重入鎖 & 不可重入鎖

  • 《可重入鎖和不可重入鎖》

    • 通過簡單程式碼舉例說明可重入鎖和不可重入鎖。
    • 可重入鎖指同一個執行緒可以再次獲得之前已經獲得的鎖。
    • 可重入鎖可以使用者避免死鎖。
    • Java中的可重入鎖：synchronized 和 java.util.concurrent.locks.ReentrantLock

  • 《ReenTrantLock可重入鎖（和synchronized的區別）總結》

    • synchronized 使用方便，編譯器來加鎖，是非公平鎖。
    • ReenTrantLock 使用靈活，鎖的公平性可以定製。
    • 相同加鎖場景下，推薦使用 synchronized。

互斥鎖 & 共享鎖

互斥鎖：同時只能有一個執行緒獲得鎖。比如，ReentrantLock 是互斥鎖，ReadWriteLock 中的寫鎖是互斥鎖。 共享鎖：可以有多個執行緒同時或的鎖。比如，Semaphore、CountDownLatch 是共享鎖，ReadWriteLock 中的讀鎖是共享鎖。

死鎖

作業系統

計算機原理

CPU

多級快取

典型的 CPU 有三級快取，距離核心越近，速度越快，空間越小。L1 一般 32k，L2 一般 256k，L3 一般12M。記憶體速度需要200個 CPU 週期，CPU 快取需要1個CPU週期。

程式

TODO

執行緒

協程

  • 《終結python協程----從yield到actor模型的實現》
    • 執行緒的排程是由作業系統負責，協程排程是程式自行負責
    • 與執行緒相比，協程減少了無謂的作業系統切換.
    • 實際上當遇到IO操作時做切換才更有意義，（因為IO操作不用佔用CPU），如果沒遇到IO操作，按照時間片切換.

Linux

設計模式

設計模式的六大原則

  • 《設計模式的六大原則》
    • 開閉原則：對擴充套件開放,對修改關閉，多使用抽象類和介面。
    • 里氏替換原則：基類可以被子類替換，使用抽象類繼承,不使用具體類繼承。
    • 依賴倒轉原則：要依賴於抽象,不要依賴於具體，針對介面程式設計,不針對實現程式設計。
    • 介面隔離原則：使用多個隔離的介面,比使用單個介面好，建立最小的介面。
    • 迪米特法則：一個軟體實體應當儘可能少地與其他實體發生相互作用，通過中間類建立聯絡。
    • 合成複用原則：儘量使用合成/聚合,而不是使用繼承。

23種常見設計模式

應用場景

  • 《細數JDK裡的設計模式》

    • 結構型模式：

      • 介面卡：用來把一個介面轉化成另一個介面，如 java.util.Arrays#asList()。
      • 橋接模式：這個模式將抽象和抽象操作的實現進行了解耦，這樣使得抽象和實現可以獨立地變化，如JDBC；
      • 組合模式：使得客戶端看來單個物件和物件的組合是同等的。換句話說，某個型別的方法同時也接受自身型別作為引數，如 Map.putAll，List.addAll、Set.addAll。
      • 裝飾者模式：動態的給一個物件附加額外的功能，這也是子類的一種替代方式，如 java.util.Collections#checkedList|Map|Set|SortedSet|SortedMap。
      • 享元模式：使用快取來加速大量小物件的訪問時間，如 valueOf(int)。
      • 代理模式：代理模式是用一個簡單的物件來代替一個複雜的或者建立耗時的物件，如 java.lang.reflect.Proxy

    • 建立模式:

      • 抽象工廠模式：抽象工廠模式提供了一個協議來生成一系列的相關或者獨立的物件，而不用指定具體物件的型別，如 java.util.Calendar#getInstance()。
      • 建造模式(Builder)：定義了一個新的類來構建另一個類的例項，以簡化複雜物件的建立，如：java.lang.StringBuilder#append()。
      • 工廠方法：就是 一個返* 回具體物件的方法，而不是多個，如 java.lang.Object#toString()、java.lang.Class#newInstance()。
      • 原型模式：使得類的例項能夠生成自身的拷貝、如：java.lang.Object#clone()。
      • 單例模式：全域性只有一個例項，如 java.lang.Runtime#getRuntime()。

    • 行為模式：

      • 責任鏈模式：通過把請求從一個物件傳遞到鏈條中下一個物件的方式，直到請求被處理完畢，以實現物件間的解耦。如 javax.servlet.Filter#doFilter()。
      • 命令模式：將操作封裝到物件內，以便儲存，傳遞和返回，如：java.lang.Runnable。
      • 直譯器模式：定義了一個語言的語法，然後解析相應語法的語句，如，java.text.Format，java.text.Normalizer。
      • 迭代器模式：提供一個一致的方法來順序訪問集合中的物件，如 java.util.Iterator。
      • 中介者模式：通過使用一箇中間物件來進行訊息分發以及減少類之間的直接依賴，java.lang.reflect.Method#invoke()。
      • 空物件模式：如 java.util.Collections#emptyList()。
      • 觀察者模式：它使得一個物件可以靈活的將訊息傳送給感興趣的物件，如 java.util.EventListener。
      • 模板方法模式：讓子類可以重寫方法的一部分，而不是整個重寫，如 java.util.Collections#sort()。

  • 《Spring-涉及到的設計模式彙總》

  • 《Mybatis使用的設計模式》

單例模式

責任鏈模式

TODO

MVC

IOC

  • 《理解 IOC》
  • 《IOC 的理解與解釋》
    • 正向控制：傳統通過new的方式。反向控制，通過容器注入物件。
    • 作用：用於模組解耦。
    • DI：Dependency Injection，即依賴注入，只關心資源使用，不關心資源來源。

AOP

UML

微服務思想

康威定律

  • 《微服務架構的理論基礎 - 康威定律》

    • 定律一：組織溝通方式會通過系統設計表達出來，就是說架構的佈局和組織結構會有相似。
    • 定律二：時間再多一件事情也不可能做的完美，但總有時間做完一件事情。一口氣吃不成胖子，先搞定能搞定的。
    • 定律三：線型系統和線型組織架構間有潛在的異質同態特性。種瓜得瓜，做獨立自治的子系統減少溝通成本。
    • 定律四：大的系統組織總是比小系統更傾向於分解。合久必分，分而治之。

  • 《微服務架構核⼼20講》

運維 & 統計 & 技術支援

常規監控

命令列監控工具

APM

APM — Application Performance Management

統計分析

持續整合(CI/CD)

Jenkins

環境分離

開發、測試、生成環境分離。

自動化運維

Ansible

puppet

chef

測試

TDD 理論

  • 《深度解讀 - TDD（測試驅動開發）》
    • 基於測試用例編碼功能程式碼，XP（Extreme Programming）的核心實踐.
    • 好處：一次關注一個點，降低思維負擔；迎接需求變化或改善程式碼的設計；提前澄清需求；快速反饋；

單元測試

壓力測試

全鏈路壓測

A/B 、灰度、藍綠測試

虛擬化

KVM

Xen

OpenVZ

容器技術

Docker

雲技術

OpenStack

DevOps

文件管理

中介軟體

Web Server

Nginx

OpenResty

Tengine

Apache Httpd

Tomcat

架構原理

調優方案

Jetty

  • 《Jetty 的工作原理以及與 Tomcat 的比較》
  • 《jetty和tomcat優勢比較》
    • 架構比較:Jetty的架構比Tomcat的更為簡單。
    • 效能比較：Jetty和Tomcat效能方面差異不大，Jetty預設採用NIO結束在處理I/O請求上更佔優勢，Tomcat預設採用BIO處理I/O請求，Tomcat適合處理少數非常繁忙的連結，處理靜態資源時效能較差。
    • 其他方面：Jetty的應用更加快速，修改簡單，對新的Servlet規範的支援較好;Tomcat 對JEE和Servlet 支援更加全面。

快取

本地快取

客戶端快取

服務端快取

Web快取

Memcached

Redis

  • 《Redis 教程》

  • 《redis底層原理》

    • 使用 ziplist 儲存連結串列，ziplist是一種壓縮連結串列，它的好處是更能節省記憶體空間，因為它所儲存的內容都是在連續的記憶體區域當中的。
    • 使用 skiplist(跳躍表)來儲存有序集合物件、查詢上先從高Level查起、時間複雜度和紅黑樹相當，實現容易，無鎖、併發性好。

  • 《Redis持久化方式》

    • RDB方式：定期備份快照，常用於災難恢復。優點：通過fork出的程式進行備份，不影響主程式、RDB 在恢復大資料集時的速度比 AOF 的恢復速度要快。缺點：會丟資料。
    • AOF方式：儲存操作日誌方式。優點：恢復時資料丟失少，缺點：檔案大，回覆慢。
    • 也可以兩者結合使用。

  • 《分散式快取--序列3--原子操作與CAS樂觀鎖》

架構

回收策略

Tair

  • 官方網站
  • 《Tair和Redis的對比》
  • 特點：可以配置備份節點數目，通過非同步同步到備份節點
  • 一致性Hash演算法。
  • 架構：和Hadoop 的設計思想類似，有Configserver，DataServer，Configserver 通過心跳來檢測，Configserver也有主備關係。

幾種儲存引擎:

  • MDB，完全記憶體性，可以用來儲存Session等資料。
  • Rdb（類似於Redis），輕量化，去除了aof之類的操作，支援Restfull操作
  • LDB（LevelDB儲存引擎），持久化儲存，LDB 作為rdb的持久化，google實現，比較高效，理論基礎是LSM(Log-Structured-Merge Tree)演算法，現在記憶體中修改資料，達到一定量時（和記憶體彙總的舊資料一同寫入磁碟）再寫入磁碟，儲存更加高效，縣比喻Hash演算法。
  • Tair採用共享記憶體來儲存資料，如果服務掛掉（非伺服器），重啟服務之後，資料亦然還在。

訊息佇列

訊息匯流排

訊息匯流排相當於在訊息佇列之上做了一層封裝，統一入口，統一管控、簡化接入成本。

訊息的順序

RabbitMQ

支援事務，推拉模式都是支援、適合需要可靠性訊息傳輸的場景。

RocketMQ

Java實現，推拉模式都是支援，吞吐量遜於Kafka。可以保證訊息順序。

ActiveMQ

純Java實現，相容JMS，可以內嵌於Java應用中。

Kafka

高吞吐量、採用拉模式。適合高IO場景，比如日誌同步。

Redis 訊息推送

生產者、消費者模式完全是客戶端行為，list 和 拉模式實現，阻塞等待採用 blpop 指令。

ZeroMQ

TODO

定時排程

單機定時排程

分散式定時排程

RPC

Dubbo

** SPI ** TODO

Thrift

gRPC

服務端可以認證加密，在外網環境下，可以保證資料安全。

資料庫中介軟體

Sharding Jdbc

日誌系統

日誌蒐集

配置中心

servlet 3.0 非同步特性可用於配置中心的客戶端

API 閘道器

主要職責：請求轉發、安全認證、協議轉換、容災。

網路

協議

OSI 七層協議

TCP/IP

HTTP

HTTP2.0

HTTPS

網路模型

  • 《web優化必須瞭解的原理之I/o的五種模型和web的三種工作模式》

    • 五種I/O模型：阻塞I/O，非阻塞I/O，I/O複用、事件(訊號)驅動I/O、非同步I/O，前四種I/O屬於同步操作，I/O的第一階段不同、第二階段相同，最後的一種則屬於非同步操作。
    • 三種 Web Server 工作方式：Prefork(多程式)、Worker方式(執行緒方式)、Event方式。

  • 《select、poll、epoll之間的區別總結》

    • select，poll，epoll本質上都是同步I/O，因為他們都需要在讀寫事件就緒後自己負責進行讀寫，也就是說這個讀寫過程是阻塞的。
    • select 有開啟檔案描述符數量限制，預設1024（2048 for x64），100萬併發，就要用1000個程式、切換開銷大；poll採用連結串列結構，沒有數量限制。
    • select，poll “醒著”的時候要遍歷整個fd集合，而epoll在“醒著”的時候只要判斷一下就緒連結串列是否為空就行了，通過回撥機制節省大量CPU時間；select，poll每次呼叫都要把fd集合從使用者態往核心態拷貝一次，而epoll只要一次拷貝。
    • poll會隨著併發增加，效能逐漸下降，epoll採用紅黑樹結構，效能穩定，不會隨著連線數增加而降低。

  • 《select，poll，epoll比較 》

    • 在連線數少並且連線都十分活躍的情況下，select和poll的效能可能比epoll好，畢竟epoll的通知機制需要很多函式回撥。

  • 《深入理解Java NIO》

    • NIO 是一種同步非阻塞的 IO 模型。同步是指執行緒不斷輪詢 IO 事件是否就緒，非阻塞是指執行緒在等待 IO 的時候，可以同時做其他任務

  • 《BIO與NIO、AIO的區別》

  • 《兩種高效的伺服器設計模型：Reactor和Proactor模型》

Epoll

Java NIO

kqueue

連線和短連線

框架

零拷貝（Zero-copy）

序列化(二進位制協議)

Hessian

Protobuf

資料庫

基礎理論

關聯式資料庫設計的三大正規化

  • 《資料庫的三大正規化以及五大約束》
    • 第一正規化：資料表中的每一列（每個欄位）必須是不可拆分的最小單元，也就是確保每一列的原子性；
    • 第二正規化（2NF）：滿足1NF後，要求表中的所有列，都必須依賴於主鍵，而不能有任何一列與主鍵沒有關係，也就是說一個表只描述一件事情；
    • 第三正規化：必須先滿足第二正規化（2NF），要求：表中的每一列只與主鍵直接相關而不是間接相關，（表中的每一列只能依賴於主鍵）；

MySQL

原理

InnoDB

優化

索引

聚集索引, 非聚集索引

MyISAM 是非聚集，InnoDB 是聚集

複合索引

  • 《複合索引的優點和注意事項》

    • 文中有一處錯誤：

    對於複合索引,在查詢使用時,最好將條件順序按找索引的順序,這樣效率最高; select * from table1 where col1=A AND col2=B AND col3=D 如果使用 where col2=B AND col1=A 或者 where col2=B 將不會使用索引

    • 原文中提到索引是按照“col1，col2，col3”的順序建立的，而mysql在按照最左字首的索引匹配原則，且會自動優化 where 條件的順序，當條件中只有 col2=B AND col1=A 時，會自動轉化為 col1=A AND col2=B，所以依然會使用索引。

  • 《MySQL查詢where條件的順序對查詢效率的影響》

自適應雜湊索引(AHI)

explain

NoSQL

MongoDB

  • MongoDB 教程
  • 《Mongodb相對於關係型資料庫的優缺點》
    • 優點：弱一致性（最終一致），更能保證使用者的訪問速度；內建GridFS，支援大容量的儲存；Schema-less 資料庫，不用預先定義結構；內建Sharding；相比於其他NoSQL，第三方支援豐富；效能優越；
    • 缺點：mongodb不支援事務操作；mongodb佔用空間過大；MongoDB沒有如MySQL那樣成熟的維護工具，這對於開發和IT運營都是個值得注意的地方；

Hbase

搜尋引擎

搜尋引擎原理

Lucene

Elasticsearch

Solr

sphinx

效能

效能優化方法論

容量評估

CDN 網路

連線池

效能調優

大資料

流式計算

Storm

Flink

Kafka Stream

應用場景

例如：

  • 廣告相關實時統計；
  • 推薦系統使用者畫像標籤實時更新；
  • 線上服務健康狀況實時監測；
  • 實時榜單；
  • 實時資料統計。

Hadoop

HDFS

MapReduce

Yarn

Spark

安全

web 安全

XSS

CSRF

SQL 注入

Hash Dos

指令碼注入

漏洞掃描工具

驗證碼

DDoS 防範

使用者隱私資訊保護

  1. 使用者密碼非明文儲存，加動態salt。
  2. 身份證號，手機號如果要顯示，用 “*” 替代部分字元。
  3. 聯絡方式在的顯示與否由使用者自己控制。
  4. TODO

序列化漏洞

加密解密

對稱加密

  • 《常見對稱加密演算法》
    • DES、3DES、Blowfish、AES
    • DES 採用 56位祕鑰，Blowfish 採用1到448位變長祕鑰，AES 128，192和256位長度的祕鑰。
    • DES 祕鑰太短（只有56位）演算法目前已經被 AES 取代，並且 AES 有硬體加速，效能很好。

雜湊演算法

非對稱加密

伺服器安全

資料安全

資料備份

TODO

網路隔離

內外網分離

TODO

登入跳板機

在內外環境中通過跳板機登入到線上主機。

授權、認證

RBAC

OAuth2.0

雙因素認證（2FA）

2FA - Two-factor authentication，用於加強登入驗證

常用做法是 登入密碼 + 手機驗證碼（或者令牌Key，類似於與網銀的 USB key）

單點登入(SSO)

常用開源框架

開源協議

日誌框架

Log4j、Log4j2

Logback

ORM

MyBatis：

網路框架

TODO

Web 框架

Spring 家族

Spring

Spring Boot

Spring Cloud

工具框架

分散式設計

擴充套件性設計

穩定性 & 高可用

  • 《系統設計：關於高可用系統的一些技術方案》

    • 可擴充套件：水平擴充套件、垂直擴充套件。 通過冗餘部署，避免單點故障。
    • 隔離：避免單一業務佔用全部資源。避免業務之間的相互影響 2. 機房隔離避免單點故障。
    • 解耦：降低維護成本，降低耦合風險。減少依賴，減少相互間的影響。
    • 限流：滑動視窗計數法、漏桶演算法、令牌桶演算法等演算法。遇到突發流量時，保證系統穩定。
    • 降級：緊急情況下釋放非核心功能的資源。犧牲非核心業務，保證核心業務的高可用。
    • 熔斷：異常情況超出閾值進入熔斷狀態，快速失敗。減少不穩定的外部依賴對核心服務的影響。
    • 自動化測試：通過完善的測試，減少釋出引起的故障。
    • 灰度釋出：灰度釋出是速度與安全性作為妥協，能夠有效減少釋出故障。

  • 《關於高可用的系統》

    • 設計原則：資料不丟(持久化)；服務高可用(服務副本)；絕對的100%高可用很難，目標是做到儘可能多的9，如99.999%（全年累計只有5分鐘）。

硬體負載均衡

軟體負載均衡

限流

  • 《談談高併發系統的限流》
    • 計數器：通過滑動視窗計數器，控制單位時間內的請求次數，簡單粗暴。
    • 漏桶演算法：固定容量的漏桶，漏桶滿了就丟棄請求，比較常用。
    • 令牌桶演算法：固定容量的令牌桶，按照一定速率新增令牌，處理請求前需要拿到令牌，拿不到令牌則丟棄請求，或進入丟佇列，可以通過控制新增令牌的速率，來控制整體速度。Guava 中的 RateLimiter 是令牌桶的實現。
    • Nginx 限流：通過 limit_req 等模組限制併發連線數。

應用層容災

  • 《防雪崩利器：熔斷器 Hystrix 的原理與使用》

    • 雪崩效應原因：硬體故障、硬體故障、程式Bug、重試加大流量、使用者大量請求。
    • 雪崩的對策：限流、改進快取模式(快取預載入、同步呼叫改非同步)、自動擴容、降級。
    • Hystrix設計原則：
      • 資源隔離：Hystrix通過將每個依賴服務分配獨立的執行緒池進行資源隔離, 從而避免服務雪崩。
      • 熔斷開關：服務的健康狀況 = 請求失敗數 / 請求總數，通過閾值設定和滑動視窗控制開關。
      • 命令模式：通過繼承 HystrixCommand 來包裝服務呼叫邏輯。

  • 《快取穿透，快取擊穿，快取雪崩解決方案分析》

  • 《快取擊穿、失效以及熱點key問題》

    • 主要策略：失效瞬間：單機使用鎖；使用分散式鎖；不過期；
    • 熱點資料：熱點資料單獨儲存；使用本地快取；分成多個子key；

跨機房容災

  • 《“異地多活”多機房部署經驗談》

    • 通過自研中介軟體進行資料同步。

  • 《異地多活（異地雙活）實踐經驗》

    • 注意延遲問題，多次跨機房呼叫會將延時放大數倍。
    • 建房間專線很大概率會出現問題，做好運維和程式層面的容錯。
    • 不能依賴於程式端資料雙寫，要有自動同步方案。
    • 資料永不在高延遲和較差網路質量下，考慮同步質量問題。
    • 核心業務和次要業務分而治之，甚至只考慮核心業務。
    • 異地多活監控部署、測試也要跟上。
    • 業務允許的情況下考慮使用者分割槽，尤其是遊戲、郵箱業務。
    • 控制跨機房訊息體大小，越小越好。
    • 考慮使用docker容器虛擬化技術，提高動態排程能力。

  • 容災技術及建設經驗介紹

容災演練流程

平滑啟動

資料庫擴充套件

讀寫分離模式

分片模式

  • 《分庫分表需要考慮的問題及方案》

    • 中介軟體： 輕量級：sharding-jdbc、TSharding；重量級：Atlas、MyCAT、Vitess等。
    • 問題：事務、Join、遷移、擴容、ID、分頁等。
    • 事務補償：對資料進行對帳檢查;基於日誌進行比對;定期同標準資料來源進行同步等。
    • 分庫策略：數值範圍；取模；日期等。
    • 分庫數量：通常 MySQL 單庫 5千萬條、Oracle 單庫一億條需要分庫。

  • 《MySql分表和表分割槽詳解》

    • 分割槽：是MySQL內部機制，對客戶端透明，資料儲存在不同檔案中，表面上看是同一個表。
    • 分表：物理上建立不同的表、客戶端需要管理分表路由。

服務治理

服務註冊與發現

服務路由控制

  • 《分散式服務框架學習筆記4 服務路由》
    • 原則：透明化路由
    • 負載均衡策略：隨機、輪詢、服務呼叫延遲、一致性雜湊、粘滯連線
    • 本地路由優先策略：injvm(優先呼叫jvm內部的服務)，innative(優先使用相同物理機的服務),原則上找距離最近的服務。
    • 配置方式：統一登錄檔；本地配置；動態下發。

分散式一致

CAP 與 BASE 理論

  • 《從分散式一致性談到CAP理論、BASE理論》
    • 一致性分類：強一致(立即一致)；弱一致(可在單位時間內實現一致，比如秒級)；最終一致(弱一致的一種，一定時間內最終一致)
    • CAP：一致性、可用性、分割槽容錯性(網路故障引起)
    • BASE：Basically Available（基本可用）、Soft state（軟狀態）和Eventually consistent（最終一致性）
    • BASE理論的核心思想是：即使無法做到強一致性，但每個應用都可以根據自身業務特點，採用適當的方式來使系統達到最終一致性。

分散式鎖

  • 《分散式鎖的幾種實現方式》

    • 基於資料庫的分散式鎖：優點：操作簡單、容易理解。缺點：存在單點問題、資料庫效能夠開銷較大、不可重入；
    • 基於快取的分散式鎖：優點：非阻塞、效能好。缺點：操作不好容易造成鎖無法釋放的情況。
    • Zookeeper 分散式鎖：通過有序臨時節點實現鎖機制，自己對應的節點需要最小，則被認為是獲得了鎖。優點：叢集可以透明解決單點問題，避免鎖不被釋放問題，同時鎖可以重入。缺點：效能不如快取方式，吞吐量會隨著zk叢集規模變大而下降。

  • 《基於Zookeeper的分散式鎖》

    • 清楚的原理描述 + Java 程式碼示例。

  • 《jedisLock—redis分散式鎖實現》

    • 基於 setnx(set if ont exists)，有則返回false，否則返回true。並支援過期時間。

  • 《Memcached 和 Redis 分散式鎖方案》

    • 利用 memcached 的 add（有別於set）操作，當key存在時，返回false。

分散式一致性演算法

PAXOS

Zab

Raft

Gossip

兩階段提交、多階段提交

冪等

  • 《分散式系統---冪等性設計》
    • 冪等特性的作用：該資源具備冪等性，請求方無需擔心重複呼叫會產生錯誤。
    • 常見保證冪等的手段：MVCC（類似於樂觀鎖）、去重表(唯一索引)、悲觀鎖、一次性token、序列號方式。

分散式一致方案

分散式 Leader 節點選舉

TCC(Try/Confirm/Cancel) 柔性事務

  • 《傳統事務與柔性事務》
    • 基於BASE理論：基本可用、柔性狀態、最終一致。
    • 解決方案：記錄日誌+補償（正向補充或者回滾）、訊息重試(要求程式要冪等)；“無鎖設計”、採用樂觀鎖機制。

分散式檔案系統

唯一ID 生成

全域性唯一ID

  • 《高併發分散式系統中生成全域性唯一Id彙總》

    • Twitter 方案（Snowflake 演算法）：41位時間戳+10位機器標識（比如IP，伺服器名稱等）+12位序列號(本地計數器)
    • Flicker 方案：MySQL自增ID + "REPLACE INTO XXX:SELECT LAST_INSERT_ID();"
    • UUID：缺點，無序，字串過長，佔用空間，影響檢索效能。
    • MongoDB 方案：利用 ObjectId。缺點：不能自增。

  • 《TDDL 在分散式下的SEQUENCE原理》

    • 在資料庫中建立 sequence 表，用於記錄，當前已被佔用的id最大值。
    • 每臺客戶端主機取一個id區間（比如 1000~2000）快取在本地，並更新 sequence 表中的id最大值記錄。
    • 客戶端主機之間取不同的id區間，用完再取，使用樂觀鎖機制控制併發。

一致性Hash演算法

設計思想 & 開發模式

DDD(Domain-driven Design - 領域驅動設計)

  • 《淺談我對DDD領域驅動設計的理解》

    • 概念：DDD 主要對傳統軟體開發流程(分析-設計-編碼)中各階段的割裂問題而提出，避免由於一開始分析不明或在軟體開發過程中的資訊流轉不一致而造成軟體無法交付（和需求方設想不一致）的問題。DDD 強調一切以領域（Domain）為中心，強調領域專家（Domain Expert）的作用，強調先定義好領域模型之後在進行開發，並且領域模型可以指導開發（所謂的驅動）。
    • 過程：理解領域、拆分領域、細化領域，模型的準確性取決於模型的理解深度。
    • 設計：DDD 中提出了建模工具，比如聚合、實體、值物件、工廠、倉儲、領域服務、領域事件來幫助領域建模。

  • 《領域驅動設計的基礎知識總結》

    • 領域（Doamin）本質上就是問題域，比如一個電商系統，一個論壇系統等。
    • 界限上下文（Bounded Context）：闡述子域之間的關係，可以簡單理解成一個子系統或元件模組。
    • 領域模型（Domain Model）：DDD的核心是建立（用通用描述語言、工具—領域通用語言）正確的領域模型；反應業務需求的本質，包括實體和過程；其貫穿軟體分析、設計、開發 的整個過程；常用表達領域模型的方式：圖、程式碼或文字；
    • 領域通用語言：領域專家、開發設計人員都能立即的語言或工具。
    • 經典分層架構：使用者介面/展示層、應用層、領域層、基礎設施層，是四層架構模式。
    • 使用的模式：
      • 關聯儘量少，儘量單項，儘量降低整體複雜度。
      • 實體（Entity）：領域中的唯一標示，一個實體的屬性儘量少，少則清晰。
      • 值物件（Value Object）：沒有唯一標識，且屬性值不可變，小二簡單的物件，比如Date。
      • 領域服務（Domain Service）： 協調多個領域物件，只有方法沒有狀態(不存資料)；可以分為應用層服務，領域層服務、基礎層服務。
      • 聚合及聚合根（Aggregate，Aggregate Root）：聚合定義了一組具有內聚關係的相關物件的集合；聚合根是對聚合引用的唯一元素；當修改一個聚合時，必須在事務級別；大部分領域模型中，有70%的聚合通常只有一個實體，30%只有2~3個實體；如果一個聚合只有一個實體，那麼這個實體就是聚合根；如果有多個實體，那麼我們可以思考聚合內哪個物件有獨立存在的意義並且可以和外部直接進行互動；
      • 工廠（Factory）：類似於設計模式中的工廠模式。
      • 倉儲（Repository）：持久化到DB，管理物件，且只對聚合設計倉儲。

  • 《領域驅動設計(DDD)實現之路》

    • 聚合：比如一輛汽車（Car）包含了引擎（Engine）、車輪（Wheel）和油箱（Tank）等元件，缺一不可。

  • 《領域驅動設計系列（2）淺析VO、DTO、DO、PO的概念、區別和用處》

命令查詢職責分離(CQRS)

CQRS — Command Query Responsibility Seperation

貧血，充血模型

  • 《貧血，充血模型的解釋以及一些經驗》
    • 失血模型：老子和兒子分別定義，相互不知道，二者實體定義中完全沒有業務邏輯，通過外部Service進行關聯。
    • 貧血模型：老子知道兒子，兒子也知道老子；部分業務邏輯放到實體中；優點：各層單項依賴，結構清楚，易於維護；缺點：不符合OO思想，相比於充血模式，Service層較為厚重；
    • 充血模型：和貧血模型類似，區別在於如何劃分業務邏輯。優點：Service層比較薄，只充當Facade的角色，不和DAO打交道、複合OO思想；缺點：非單項依賴，DO和DAO之間雙向依賴、和Service層的邏輯劃分容易造成混亂。
    • 腫脹模式：是一種極端情況，取消Service層、全部業務邏輯放在DO中；優點：符合OO思想、簡化了分層；缺點：暴露資訊過多、很多非DO邏輯也會強行併入DO。這種模式應該避免。
    • 作者主張使用貧血模式。

Actor 模式

TODO

響應式程式設計

Reactor

TODO

RxJava

TODO

Vert.x

TODO

DODAF2.0

Serverless

無需過多關係伺服器的服務架構理念。

  • 《什麼是Serverless無伺服器架構？》

    • Serverless 不代表出去伺服器，而是去除對伺服器執行狀態的關心。
    • Serverless 代表一思維方式的轉變，從“構建一套服務在一臺伺服器上，對對個事件進行響應轉變為構建一個為伺服器，來響應一個事件”。
    • Serverless 不代表某個具體的框架。

  • 《如何理解Serverless？》

    • 依賴於 Baas （(Mobile) Backend as a Service） 和 Faas （Functions as a service）

Service Mesh

專案管理

架構評審

重構

程式碼規範

程式碼 Review

制度還是制度! 另外，每個公司需要根據自己的需求和目標制定自己的 check list

RUP

看板管理

SCRUM

SCRUM - 爭球

敏捷開發

TODO

極限程式設計（XP）

XP - eXtreme Programming

  • 《主流敏捷開發方法：極限程式設計XP》

    • 是一種指導開發人員的方法論。

    • 4大價值：

      • 溝通：鼓勵口頭溝通，提高效率。
      • 簡單：夠用就好。
      • 反饋：及時反饋、通知相關人。
      • 勇氣：提倡擁抱變化，敢於重構。

    • 5個原則：快速反饋、簡單性假設、逐步修改、提倡更改（小步快跑）、優質工作（保證質量的前提下保證小步快跑）。

    • 5個工作：階段性衝刺；衝刺計劃會議；每日站立會議；衝刺後review；回顧會議。

結對程式設計

邊寫碼，邊review。能夠增強程式碼質量、減少bug。

PDCA 迴圈質量管理

P——PLAN 策劃，D——DO 實施，C——CHECK 檢查，A——ACT 改進

FMEA管理模式

TODO

通用業務術語

TODO

技術趨勢

TODO

政策、法規

法律

嚴格遵守刑法253法條

我國刑法第253條之一規定：

  • 國家機關或者金融、電信、交通、教育、醫療等單位的工作人員，違反國家規定，將本單位在履行職責或者提供服務過程中獲得的公民個人資訊，出售或者非法提供給他人，情節嚴重的，處3年以下有期徒刑或者拘役，並處或者單處罰金。
  • 竊取或者以其他方法非法獲取上述資訊，情節嚴重的，依照前款的規定處罰。
  • 單位犯前兩款罪的，對單位判處罰金，並對其直接負責的主管人員和其他直接責任人員，依照各該款的規定處罰。

最高人民法院、最高人民檢察院關於執行《中華人民共和國刑法》確定罪名的補充規定（四）規定：觸犯刑法第253條之一第1款之規定，構成“出售、非法提供公民個人資訊罪”；觸犯刑法第253條之一第2款之規定，構成“非法獲取公民個人資訊罪”

避風港原則

“避風港”原則是指在發生著作權侵權案件時，當ISP（網路服務提供商）只提供空間服務，並不製作網頁內容，如果ISP被告知侵權，則有刪除的義務，否則就被視為侵權。如果侵權內容既不在ISP的伺服器上儲存，又沒有被告知哪些內容應該刪除，則ISP不承擔侵權責任。 後來避風港原則也被應用在搜尋引擎、網路儲存、線上圖書館等方面。

架構師素質

  • 《架構師畫像》

    • 業務理解和抽象能力
    • NB的程式碼能力
    • 全面：1. 在面對業務問題上，架構師腦海裡是否會浮現出多種技術方案；2. 在做系統設計時是否考慮到了足夠多的方方面面；3. 在做系統設計時是否考慮到了足夠多的方方面面；
    • 全域性：是否考慮到了對上下游的系統的影響。
    • 權衡：權衡投入產出比；優先順序和節奏控制；

  • 《關於架構優化和設計，架構師必須知道的事情》

    • 要去考慮的細節：模組化、輕耦合、無共享架構；減少各個元件之前的依賴、注意服務之間依賴所有造成的鏈式失敗及影響等。
    • 基礎設施、配置、測試、開發、運維綜合考慮。
    • 考慮人、團隊、和組織的影響。

  • 《如何才能真正的提高自己，成為一名出色的架構師？》

  • 《架構師的必備素質和成長途徑》

    • 素質：業務理解、技術廣度、技術深度、豐富經驗、溝通能力、動手能力、美學素養。
    • 成長路徑：2年積累知識、4年積累技能和組內影響力、7年積累部門內影響力、7年以上積累跨部門影響力。

  • 《架構設計師—你在哪層樓？》

    • 第一層的架構師看到的只是產品本身
    • 第二層的架構師不僅看到自己的產品，還看到了整體的方案
    • 第三層的架構師看到的是商業價值

團隊管理

TODO

招聘

資訊

行業資訊

公眾號列表

TODO

部落格

團隊部落格

個人部落格

綜合門戶、社群

國內：

國外：

問答、討論類社群

行業資料分析

專項網站

其他類

推薦參考書

線上電子書

紙質書

更多架構方面書籍參考: awesome-java-books

開發方面

  • 《阿里巴巴Java開發手冊》詳情

架構方面

  • 《軟體架構師的12項修煉：技術技能篇》詳情

  • 《架構之美》詳情

  • 《分散式服務架構》詳情

  • 《聊聊架構》 詳情

  • 《雲原生應用架構實踐》詳情

  • 《億級流量網站架構核心技術》詳情

  • 《淘寶技術這十年》詳情

  • 《企業IT架構轉型之道-中臺戰略思想與架構實戰》 詳情

  • 《高可用架構（第1卷）》詳情

技術管理方面

  • 《CTO說》詳情
  • 《技術管理之巔》詳情
  • 《網易一千零一夜：網際網路產品專案管理實戰》詳情

基礎理論

工具方面

TODO

大資料方面

技術資源

開源資源

手冊、文件、教程

國內：

  • W3Cschool

  • Runoob.com

    • HTML 、 CSS、XML、Java、Python、PHP、設計模式等入門手冊。

  • Love2.io

    • 很多很多中文線上電子書，是一個全新的開源技術文件分享平臺。

  • gitbook.cn

    • 付費電子書。

  • ApacheCN

    • AI、大資料方面系列中文文件。

國外：

  • Quick Code
    • 免費線上技術教程。
  • gitbook.com
    • 有部分中文電子書。
  • Cheatography
    • Cheat Sheets 大全，單頁文件網站。
  • Tutorialspoint
    • 知名教程網站，提供Java、Python、JS、SQL、大資料等高質量入門教程。

線上課堂

會議、活動

活動釋出平臺:

常用APP

找工作

工具

程式碼託管

檔案服務

  • 七牛
  • 又拍雲

綜合雲服務商

VPS

相關文章