《後端架構師技術圖譜》

時間  2019-12-05
標籤 後端架構師技術圖譜 简体版
原文   原文鏈接

《後端架構師技術圖譜》

 

最後更新於20180427php

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

數據結構

隊列

集合

鏈表、數組

字典、關聯數組

棧

樹

二叉樹

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

徹底二叉樹

  • 《徹底二叉樹》
    • 葉節點只能出如今最下層和次下層，而且最下面一層的結點都集中在該層最左邊的若干位置的二叉樹。

平衡二叉樹

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

二叉查找樹（BST）

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

紅黑樹

B-，B+，B*樹

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

LSM 樹

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

  • 《LSM樹 VS B+樹》git

    • 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 等。 核心原理：將每條數據經過計算產生一個指紋（一個字節或多個字節，但必定比原始數據要少不少），其中每一位都是經過隨機計算得到，在將指紋映射到一個大的按位存儲的空間中。注意：會有必定的錯誤率。 優勢：空間和時間效率都很高。 缺點：隨着存入的元素數量增長，誤算率隨之增長。

字符串比較

KPM 算法

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

深度優先、廣度優先

貪心算法

回溯算法

剪枝算法

動態規劃

樸素貝葉斯

推薦算法

最小生成樹算法

最短路徑算法

併發

多線程

線程安全

一致性、事務

事務 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

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 支持更加全面。

緩存

本地緩存

客戶端緩存

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 是彙集

複合索引

自適應哈希索引(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. 用戶密碼非明文保存，加動態slat。
  2. 身份證號，手機號若是要顯示，用 「*」 替代部分字符。
  3. 聯繫方式在的顯示與否由用戶本身控制。
  4. TODO

序列化漏洞

加密解密

對稱加密

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

哈希算法

非對稱加密

  • 《常見非對稱加密算法》

    • RSA、DSA、ECDSA(螺旋曲線加密算法)

    • 和 RSA 不一樣的是 DSA 僅能用於數字簽名，不能進行數據加密解密，其安全性和RSA至關，但其性能要比RSA快。

    • 256位的ECC祕鑰的安全性等同於3072位的RSA祕鑰。

      《區塊鏈的加密技術》

服務器安全

數據安全

數據備份

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

TODO

Service Mesh

TODO

項目管理

架構評審

重構

代碼規範

TODO

代碼 Review

制度仍是制度! 另外，每一個公司須要根據本身的需求和目標制定本身的 check list

RUP

看板管理

SCRUM

SCRUM - 爭球

敏捷開發

TODO

極限編程（XP）

XP - eXtreme Programming

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

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

    • 4大價值：

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

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

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

結對編程

邊寫碼，邊review。可以加強代碼質量、減小bug。

FMEA管理模式

TODO

通用業務術語

TODO

技術趨勢

TODO

政策、法規

TODO

法律

嚴格遵照刑法253法條

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

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

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

架構師素質

  • 《架構師畫像》

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

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

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

  • 《如何才能真正的提升本身，成爲一名出色的架構師？》

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

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

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

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

團隊管理

TODO

招聘

資訊

行業資訊

公衆號列表

TODO

博客

團隊博客

我的博客

綜合門戶、社區

國內：

國外：

問答、討論類社區

行業數據分析

專項網站

其餘類

推薦參考書

在線電子書

紙質書

開發方面

架構方面

技術管理方面

基礎理論

工具方面

TODO

大數據方面

技術資源

開源資源

手冊、文檔、教程

國內：

  • W3Cschool

  • Runoob.com

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

  • Love2.io

    • 不少不少中文在線電子書，是一個全新的開源技術文檔分享平臺。

  • gitbook.cn

    • 付費電子書。

  • ApacheCN

    • AI、大數據方面系列中文文檔。

國外：

在線課堂

會議、活動

活動發佈平臺:

經常使用APP

找工做

工具

代碼託管

文件服務

  • 七牛
  • 又拍雲

綜合雲服務商

  • 阿里雲
  • 騰訊雲
  • 百度雲
  • 新浪雲
  • 金山雲
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程