2018-05-17 架構(gòu)師技能圖譜铭若，搞懂這些找工作無敵

原文地址： https://github.com/xingshaocheng/architect-awesome

<h1>《后端架構(gòu)師技術(shù)圖譜》</h1>

更新于20180513

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

數(shù)據(jù)結(jié)構(gòu)

隊(duì)列

集合

鏈表趾徽、數(shù)組

字典续滋、關(guān)聯(lián)數(shù)組

棧

樹

二叉樹

每個節(jié)點(diǎn)最多有兩個葉子節(jié)點(diǎn)。

完全二叉樹

  • 《完全二叉樹》
    • 葉節(jié)點(diǎn)只能出現(xiàn)在最下層和次下層，并且最下面一層的結(jié)點(diǎn)都集中在該層最左邊的若干位置的二叉樹。

平衡二叉樹

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

二叉查找樹（BST）

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

紅黑樹

B-，B+熬粗，B*樹

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

LSM 樹

LSM（Log-Structured Merge-Trees）和 B+ 樹相比，是犧牲了部分讀的性能來換取寫的性能(通過批量寫入)猜拾，實(shí)現(xiàn)讀寫之間的即舌。
Hbase、LevelDB挎袜、Tair（Long DB）顽聂、nessDB 采用 LSM 樹的結(jié)構(gòu)。LSM可以快速建立索引盯仪。

  • 《LSM樹 VS B+樹》

    • B+ 樹讀性能好紊搪，但由于需要有序結(jié)構(gòu)，當(dāng)key比較分散時全景，磁盤尋道頻繁耀石，造成寫性能。
    • LSM 是將一個大樹拆分成N棵小樹爸黄，先寫到內(nèi)存（無尋道問題滞伟，性能高），在內(nèi)存中構(gòu)建一顆有序小樹（有序樹）炕贵，隨著小樹越來越大梆奈，內(nèi)存的小樹會flush到磁盤上。當(dāng)讀時鲁驶，由于不知道數(shù)據(jù)在哪棵小樹上，因此必須遍歷（二分查找）所有的小樹舞骆，但在每顆小樹內(nèi)部數(shù)據(jù)是有序的钥弯。

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

    • 極端的說，基于LSM樹實(shí)現(xiàn)的HBase的寫性能比MySQL高了一個數(shù)量級督禽，讀性能低了一個數(shù)量級脆霎。
    • 優(yōu)化方式：Bloom filter 替代二分查找；compact 小數(shù)位大樹狈惫，提高查詢性能睛蛛。
    • Hbase 中，內(nèi)存中達(dá)到一定閾值后胧谈，整體flush到磁盤上忆肾、形成一個文件（B+數(shù)），HDFS不支持update操作菱肖，所以Hbase做整體flush而不是merge update客冈。flush到磁盤上的小樹，定期會合并成一個大樹稳强。

BitSet

經(jīng)常用于大規(guī)模數(shù)據(jù)的排重檢查场仲。

常用算法

排序和悦、查找算法

選擇排序

冒泡排序

插入排序

快速排序

歸并排序

希爾排序

TODO

堆排序

  • 《圖解排序算法(三)之堆排序》
    • 排序過程就是構(gòu)建最大堆的過程，最大堆：每個結(jié)點(diǎn)的值都大于或等于其左右孩子結(jié)點(diǎn)的值谁不，堆頂元素是最大值坐梯。

計(jì)數(shù)排序

桶排序

基數(shù)排序

按照個位挫掏、十位侦另、百位、...依次來排尉共。

二分查找

Java 中的排序工具

布隆過濾器

常用于大數(shù)據(jù)的排重支竹，比如email，url 等鸠按。
核心原理：將每條數(shù)據(jù)通過計(jì)算產(chǎn)生一個指紋（一個字節(jié)或多個字節(jié)礼搁，但一定比原始數(shù)據(jù)要少很多），其中每一位都是通過隨機(jī)計(jì)算獲得目尖，在將指紋映射到一個大的按位存儲的空間中叹坦。注意：會有一定的錯誤率。
優(yōu)點(diǎn)：空間和時間效率都很高卑雁。
缺點(diǎn)：隨著存入的元素?cái)?shù)量增加募书，誤算率隨之增加绪囱。

字符串比較

KMP 算法

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

深度優(yōu)先篮赢、廣度優(yōu)先

貪心算法

回溯算法

剪枝算法

動態(tài)規(guī)劃

樸素貝葉斯

推薦算法

最小生成樹算法

最短路徑算法

并發(fā)

Java 并發(fā)

多線程

線程安全

一致性齿椅、事務(wù)

事務(wù) ACID 特性

事務(wù)的隔離級別

  • 未提交讀：一個事務(wù)可以讀取另一個未提交的數(shù)據(jù)，容易出現(xiàn)臟讀的情況启泣。

  • 讀提交：一個事務(wù)等另外一個事務(wù)提交之后才可以讀取數(shù)據(jù)涣脚，但會出現(xiàn)不可重復(fù)讀的情況（多次讀取的數(shù)據(jù)不一致），讀取過程中出現(xiàn)UPDATE操作寥茫，會多遣蚀。（大多數(shù)數(shù)據(jù)庫默認(rèn)級別是RC，比如SQL Server纱耻，Oracle）芭梯，讀取的時候不可以修改。

  • 可重復(fù)讀： 同一個事務(wù)里確保每次讀取的時候弄喘，獲得的是同樣的數(shù)據(jù)玖喘，但不保障原始數(shù)據(jù)被其他事務(wù)更新（幻讀），Mysql InnoDB 就是這個級別蘑志。

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

  • 《理解事務(wù)的4種隔離級別》

  • 數(shù)據(jù)庫事務(wù)的四大特性及事務(wù)隔離級別

  • 《MySQL的InnoDB的幻讀問題 》

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

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

    • 圖解臟讀急但、不可重復(fù)讀澎媒、幻讀問題。

MVCC

鎖

Java中的鎖和同步類

公平鎖 & 非公平鎖

公平鎖的作用就是嚴(yán)格按照線程啟動的順序來執(zhí)行的，不允許其他線程插隊(duì)執(zhí)行的贫奠；而非公平鎖是允許插隊(duì)的唬血。

  • 《公平鎖與非公平鎖》
    • 默認(rèn)情況下 ReentrantLock 和 synchronized 都是非公平鎖。ReentrantLock 可以設(shè)置成公平鎖唤崭。

悲觀鎖

悲觀鎖如果使用不當(dāng)（鎖的條數(shù)過多）拷恨，會引起服務(wù)大面積等待。推薦優(yōu)先使用樂觀鎖+重試谢肾。

樂觀鎖 & CAS

ABA 問題

由于高并發(fā)，在CAS下噪舀，更新后可能此A非彼A。通過版本號可以解決飘诗，類似于上文Mysql 中提到的的樂觀鎖与倡。

CopyOnWrite容器

可以對CopyOnWrite容器進(jìn)行并發(fā)的讀昆稿，而不需要加鎖纺座。CopyOnWrite并發(fā)容器用于讀多寫少的并發(fā)場景。比如白名單溉潭，黑名單净响，商品類目的訪問和更新場景，不適合需要數(shù)據(jù)強(qiáng)一致性的場景喳瓣。

RingBuffer

可重入鎖 & 不可重入鎖

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

    • 通過簡單代碼舉例說明可重入鎖和不可重入鎖犹芹。
    • 可重入鎖指同一個線程可以再次獲得之前已經(jīng)獲得的鎖崎页。
    • 可重入鎖可以用戶避免死鎖。
    • Java中的可重入鎖：synchronized 和 java.util.concurrent.locks.ReentrantLock

  • 《ReenTrantLock可重入鎖（和synchronized的區(qū)別）總結(jié)》

    • synchronized 使用方便腰埂，編譯器來加鎖实昨，是非公平鎖。
    • ReenTrantLock 使用靈活盐固，鎖的公平性可以定制荒给。
    • 相同加鎖場景下，推薦使用 synchronized刁卜。

互斥鎖 & 共享鎖

互斥鎖：同時只能有一個線程獲得鎖志电。比如，ReentrantLock 是互斥鎖蛔趴，ReadWriteLock 中的寫鎖是互斥鎖挑辆。
共享鎖：可以有多個線程同時或的鎖。比如孝情，Semaphore鱼蝉、CountDownLatch 是共享鎖，ReadWriteLock 中的讀鎖是共享鎖箫荡。

死鎖

操作系統(tǒng)

計(jì)算機(jī)原理

CPU

多級緩存

典型的 CPU 有三級緩存低矮，距離核心越近印叁，速度越快，空間越小军掂。L1 一般 32k轮蜕，L2 一般 256k，L3 一般12M良姆。內(nèi)存速度需要200個 CPU 周期肠虽，CPU 緩存需要1個CPU周期幔戏。

進(jìn)程

TODO

線程

協(xié)程

  • 《終結(jié)python協(xié)程----從yield到actor模型的實(shí)現(xiàn)》
    • 線程的調(diào)度是由操作系統(tǒng)負(fù)責(zé)玛追，協(xié)程調(diào)度是程序自行負(fù)責(zé)
    • 與線程相比，協(xié)程減少了無謂的操作系統(tǒng)切換.
    • 實(shí)際上當(dāng)遇到IO操作時做切換才更有意義，（因?yàn)镮O操作不用占用CPU）痊剖，如果沒遇到IO操作韩玩，按照時間片切換.

Linux

設(shè)計(jì)模式

設(shè)計(jì)模式的六大原則

  • 《設(shè)計(jì)模式的六大原則》
    • 開閉原則：對擴(kuò)展開放,對修改關(guān)閉，多使用抽象類和接口陆馁。
    • 里氏代換原則：基類可以被子類替換找颓，使用抽象類繼承,不使用具體類繼承。
    • 依賴倒轉(zhuǎn)原則：要依賴于抽象,不要依賴于具體叮贩，針對接口編程,不針對實(shí)現(xiàn)編程击狮。
    • 接口隔離原則：使用多個隔離的接口,比使用單個接口好，建立最小的接口益老。
    • 迪米特法則：一個軟件實(shí)體應(yīng)當(dāng)盡可能少地與其他實(shí)體發(fā)生相互作用彪蓬，通過中間類建立聯(lián)系。
    • 合成復(fù)用原則：盡量使用合成/聚合,而不是使用繼承捺萌。

23種常見設(shè)計(jì)模式

應(yīng)用場景

  • 《細(xì)數(shù)JDK里的設(shè)計(jì)模式》

    • 結(jié)構(gòu)型模式：

      • 適配器：用來把一個接口轉(zhuǎn)化成另一個接口档冬，如 java.util.Arrays#asList()。
      • 橋接模式：這個模式將抽象和抽象操作的實(shí)現(xiàn)進(jìn)行了解耦桃纯，這樣使得抽象和實(shí)現(xiàn)可以獨(dú)立地變化酷誓，如JDBC；
      • 組合模式：使得客戶端看來單個對象和對象的組合是同等的态坦。換句話說盐数，某個類型的方法同時也接受自身類型作為參數(shù)，如 Map.putAll伞梯，List.addAll娘扩、Set.addAll。
      • 裝飾者模式：動態(tài)的給一個對象附加額外的功能壮锻，這也是子類的一種替代方式琐旁，如 java.util.Collections#checkedList|Map|Set|SortedSet|SortedMap。
      • 享元模式：使用緩存來加速大量小對象的訪問時間猜绣，如 valueOf(int)灰殴。
      • 代理模式：代理模式是用一個簡單的對象來代替一個復(fù)雜的或者創(chuàng)建耗時的對象，如 java.lang.reflect.Proxy

    • 創(chuàng)建模式:

      • 抽象工廠模式：抽象工廠模式提供了一個協(xié)議來生成一系列的相關(guān)或者獨(dú)立的對象掰邢，而不用指定具體對象的類型牺陶，如 java.util.Calendar#getInstance()。
      • 建造模式(Builder)：定義了一個新的類來構(gòu)建另一個類的實(shí)例辣之，以簡化復(fù)雜對象的創(chuàng)建掰伸，如：java.lang.StringBuilder#append()。
      • 工廠方法：就是 一個返* 回具體對象的方法怀估，而不是多個狮鸭，如 java.lang.Object#toString()合搅、java.lang.Class#newInstance()。
      • 原型模式：使得類的實(shí)例能夠生成自身的拷貝歧蕉、如：java.lang.Object#clone()灾部。
      • 單例模式：全局只有一個實(shí)例，如 java.lang.Runtime#getRuntime()惯退。

    • 行為模式：

      • 責(zé)任鏈模式：通過把請求從一個對象傳遞到鏈條中下一個對象的方式赌髓，直到請求被處理完畢，以實(shí)現(xiàn)對象間的解耦催跪。如 javax.servlet.Filter#doFilter()锁蠕。
      • 命令模式：將操作封裝到對象內(nèi)，以便存儲懊蒸，傳遞和返回匿沛，如：java.lang.Runnable。
      • 解釋器模式：定義了一個語言的語法榛鼎，然后解析相應(yīng)語法的語句逃呼，如，java.text.Format者娱，java.text.Normalizer抡笼。
      • 迭代器模式：提供一個一致的方法來順序訪問集合中的對象，如 java.util.Iterator黄鳍。
      • 中介者模式：通過使用一個中間對象來進(jìn)行消息分發(fā)以及減少類之間的直接依賴推姻，java.lang.reflect.Method#invoke()。
      • 空對象模式：如 java.util.Collections#emptyList()框沟。
      • 觀察者模式：它使得一個對象可以靈活的將消息發(fā)送給感興趣的對象藏古，如 java.util.EventListener。
      • 模板方法模式：讓子類可以重寫方法的一部分忍燥，而不是整個重寫拧晕，如 java.util.Collections#sort()。

  • 《Spring-涉及到的設(shè)計(jì)模式匯總》

  • 《Mybatis使用的設(shè)計(jì)模式》

單例模式

責(zé)任鏈模式

TODO

MVC

IOC

  • 《理解 IOC》
  • 《IOC 的理解與解釋》
    • 正向控制：傳統(tǒng)通過new的方式厂捞。反向控制，通過容器注入對象队丝。
    • 作用：用于模塊解耦靡馁。
    • DI：Dependency Injection，即依賴注入机久，只關(guān)心資源使用臭墨，不關(guān)心資源來源。

AOP

UML

微服務(wù)思想

康威定律

  • 《微服務(wù)架構(gòu)的理論基礎(chǔ) - 康威定律》

    • 定律一：組織溝通方式會通過系統(tǒng)設(shè)計(jì)表達(dá)出來，就是說架構(gòu)的布局和組織結(jié)構(gòu)會有相似践图。
    • 定律二：時間再多一件事情也不可能做的完美掺冠，但總有時間做完一件事情。一口氣吃不成胖子码党，先搞定能搞定的德崭。
    • 定律三：線型系統(tǒng)和線型組織架構(gòu)間有潛在的異質(zhì)同態(tài)特性。種瓜得瓜揖盘，做獨(dú)立自治的子系統(tǒng)減少溝通成本眉厨。
    • 定律四：大的系統(tǒng)組織總是比小系統(tǒng)更傾向于分解。合久必分兽狭，分而治之憾股。

  • 《微服務(wù)架構(gòu)核?20講》

運(yùn)維 & 統(tǒng)計(jì) & 技術(shù)支持

常規(guī)監(jiān)控

命令行監(jiān)控工具

APM

APM — Application Performance Management

統(tǒng)計(jì)分析

持續(xù)集成(CI/CD)

Jenkins

環(huán)境分離

開發(fā)、測試碱妆、生成環(huán)境分離肉盹。

自動化運(yùn)維

Ansible

puppet

chef

測試

TDD 理論

  • 《深度解讀 - TDD（測試驅(qū)動開發(fā)）》
    • 基于測試用例編碼功能代碼上忍，XP（Extreme Programming）的核心實(shí)踐.
    • 好處：一次關(guān)注一個點(diǎn)，降低思維負(fù)擔(dān)纳本；迎接需求變化或改善代碼的設(shè)計(jì)窍蓝；提前澄清需求；快速反饋繁成；

單元測試

壓力測試

全鏈路壓測

A/B 幌墓、灰度但壮、藍(lán)綠測試

虛擬化

KVM

Xen

OpenVZ

容器技術(shù)

Docker

云技術(shù)

OpenStack

DevOps

文檔管理

中間件

Web Server

Nginx

OpenResty

Apache Httpd

Tomcat

架構(gòu)原理

調(diào)優(yōu)方案

Jetty

  • 《Jetty 的工作原理以及與 Tomcat 的比較》
  • 《jetty和tomcat優(yōu)勢比較》
    • 架構(gòu)比較:Jetty的架構(gòu)比Tomcat的更為簡單封孙。
    • 性能比較：Jetty和Tomcat性能方面差異不大，Jetty默認(rèn)采用NIO結(jié)束在處理I/O請求上更占優(yōu)勢讽营，Tomcat默認(rèn)采用BIO處理I/O請求虎忌，Tomcat適合處理少數(shù)非常繁忙的鏈接，處理靜態(tài)資源時性能較差橱鹏。
    • 其他方面：Jetty的應(yīng)用更加快速膜蠢，修改簡單，對新的Servlet規(guī)范的支持較好;Tomcat 對JEE和Servlet 支持更加全面莉兰。

緩存

本地緩存

客戶端緩存

服務(wù)端緩存

Web緩存

Memcached

Redis

  • 《Redis 教程》

  • 《redis底層原理》

    • 使用 ziplist 存儲鏈表品山，ziplist是一種壓縮鏈表，它的好處是更能節(jié)省內(nèi)存空間烤低，因?yàn)樗鎯Φ膬?nèi)容都是在連續(xù)的內(nèi)存區(qū)域當(dāng)中的肘交。
    • 使用 skiplist(跳躍表)來存儲有序集合對象、查找上先從高Level查起扑馁、時間復(fù)雜度和紅黑樹相當(dāng)涯呻，實(shí)現(xiàn)容易，無鎖腻要、并發(fā)性好复罐。

  • 《Redis持久化方式》

    • RDB方式：定期備份快照，常用于災(zāi)難恢復(fù)雄家。優(yōu)點(diǎn)：通過fork出的進(jìn)程進(jìn)行備份焕梅，不影響主進(jìn)程零聚、RDB 在恢復(fù)大數(shù)據(jù)集時的速度比 AOF 的恢復(fù)速度要快杠人。缺點(diǎn)：會丟數(shù)據(jù)砰粹。
    • AOF方式：保存操作日志方式蛛淋。優(yōu)點(diǎn)：恢復(fù)時數(shù)據(jù)丟失少咙好，缺點(diǎn)：文件大，回復(fù)慢褐荷。
    • 也可以兩者結(jié)合使用勾效。

  • 《分布式緩存--序列3--原子操作與CAS樂觀鎖》

架構(gòu)

回收策略

Tair

  • 官方網(wǎng)站
  • 《Tair和Redis的對比》
  • 特點(diǎn)：可以配置備份節(jié)點(diǎn)數(shù)目，通過異步同步到備份節(jié)點(diǎn)
  • 一致性Hash算法叛甫。
  • 架構(gòu)：和Hadoop 的設(shè)計(jì)思想類似层宫，有Configserver，DataServer其监，Configserver 通過心跳來檢測萌腿，Configserver也有主備關(guān)系。

幾種存儲引擎:

  • MDB抖苦，完全內(nèi)存性毁菱，可以用來存儲Session等數(shù)據(jù)。
  • Rdb（類似于Redis）锌历，輕量化贮庞，去除了aof之類的操作，支持Restfull操作
  • LDB（LevelDB存儲引擎）究西，持久化存儲窗慎，LDB 作為rdb的持久化，google實(shí)現(xiàn)，比較高效遮斥，理論基礎(chǔ)是LSM(Log-Structured-Merge Tree)算法峦失，現(xiàn)在內(nèi)存中修改數(shù)據(jù)，達(dá)到一定量時（和內(nèi)存匯總的舊數(shù)據(jù)一同寫入磁盤）再寫入磁盤术吗，存儲更加高效宠进，縣比喻Hash算法。
  • Tair采用共享內(nèi)存來存儲數(shù)據(jù)藐翎，如果服務(wù)掛掉（非服務(wù)器）材蹬，重啟服務(wù)之后，數(shù)據(jù)亦然還在吝镣。

消息隊(duì)列

消息總線

消息總線相當(dāng)于在消息隊(duì)列之上做了一層封裝乓旗，統(tǒng)一入口，統(tǒng)一管控集索、簡化接入成本屿愚。

消息的順序

RabbitMQ

支持事務(wù)，推拉模式都是支持务荆、適合需要可靠性消息傳輸?shù)膱鼍啊?/p>

RocketMQ

Java實(shí)現(xiàn)妆距，推拉模式都是支持，吞吐量遜于Kafka函匕∮榫荩可以保證消息順序。

ActiveMQ

純Java實(shí)現(xiàn)中剩，兼容JMS，可以內(nèi)嵌于Java應(yīng)用中酷窥。

Kafka

高吞吐量咽安、采用拉模式。適合高IO場景蓬推，比如日志同步妆棒。

Redis 消息推送

生產(chǎn)者、消費(fèi)者模式完全是客戶端行為红选，list 和 拉模式實(shí)現(xiàn)澜公，阻塞等待采用 blpop 指令。

ZeroMQ

TODO

定時調(diào)度

單機(jī)定時調(diào)度

分布式定時調(diào)度

RPC

Dubbo

** SPI **
TODO

Thrift

gRPC

服務(wù)端可以認(rèn)證加密看锉，在外網(wǎng)環(huán)境下姿锭，可以保證數(shù)據(jù)安全。

數(shù)據(jù)庫中間件

Sharding Jdbc

日志系統(tǒng)

日志搜集

配置中心

servlet 3.0 異步特性可用于配置中心的客戶端

API 網(wǎng)關(guān)

主要職責(zé)：請求轉(zhuǎn)發(fā)呻此、安全認(rèn)證、協(xié)議轉(zhuǎn)換腔寡、容災(zāi)焚鲜。

網(wǎng)絡(luò)

協(xié)議

OSI 七層協(xié)議

TCP/IP

HTTP

HTTP2.0

HTTPS

網(wǎng)絡(luò)模型

  • 《web優(yōu)化必須了解的原理之I/o的五種模型和web的三種工作模式》

    • 五種I/O模型：阻塞I/O吨些，非阻塞I/O搓谆，I/O復(fù)用、事件(信號)驅(qū)動I/O豪墅、異步I/O挽拔，前四種I/O屬于同步操作，I/O的第一階段不同但校、第二階段相同螃诅，最后的一種則屬于異步操作。
    • 三種 Web Server 工作方式：Prefork(多進(jìn)程)状囱、Worker方式(線程方式)术裸、Event方式。

  • 《select亭枷、poll袭艺、epoll之間的區(qū)別總結(jié)》

    • select，poll叨粘，epoll本質(zhì)上都是同步I/O猾编，因?yàn)樗麄兌夹枰谧x寫事件就緒后自己負(fù)責(zé)進(jìn)行讀寫，也就是說這個讀寫過程是阻塞的升敲。
    • select 有打開文件描述符數(shù)量限制答倡，默認(rèn)1024（2048 for x64），100萬并發(fā)驴党，就要用1000個進(jìn)程瘪撇、切換開銷大；poll采用鏈表結(jié)構(gòu)港庄，沒有數(shù)量限制倔既。
    • select，poll “醒著”的時候要遍歷整個fd集合鹏氧，而epoll在“醒著”的時候只要判斷一下就緒鏈表是否為空就行了渤涌，通過回調(diào)機(jī)制節(jié)省大量CPU時間；select把还，poll每次調(diào)用都要把fd集合從用戶態(tài)往內(nèi)核態(tài)拷貝一次实蓬，而epoll只要一次拷貝稿存。
    • poll會隨著并發(fā)增加，性能逐漸下降瞳秽，epoll采用紅黑樹結(jié)構(gòu)瓣履，性能穩(wěn)定，不會隨著連接數(shù)增加而降低练俐。

  • 《select袖迎，poll，epoll比較 》

    • 在連接數(shù)少并且連接都十分活躍的情況下腺晾，select和poll的性能可能比epoll好燕锥，畢竟epoll的通知機(jī)制需要很多函數(shù)回調(diào)。

  • 《深入理解Java NIO》

    • NIO 是一種同步非阻塞的 IO 模型悯蝉。同步是指線程不斷輪詢 IO 事件是否就緒归形，非阻塞是指線程在等待 IO 的時候，可以同時做其他任務(wù)

  • 《BIO與NIO鼻由、AIO的區(qū)別》

  • 《兩種高效的服務(wù)器設(shè)計(jì)模型：Reactor和Proactor模型》

Epoll

Java NIO

kqueue

連接和短連接

框架

零拷貝（Zero-copy）

序列化(二進(jìn)制協(xié)議)

Hessian

Protobuf

數(shù)據(jù)庫

基礎(chǔ)理論

數(shù)據(jù)庫設(shè)計(jì)的三大范式

  • 《數(shù)據(jù)庫的三大范式以及五大約束》
    • 第一范式：數(shù)據(jù)表中的每一列（每個字段）必須是不可拆分的最小單元湖蜕，也就是確保每一列的原子性逻卖；
    • 第二范式（2NF）：滿足1NF后，要求表中的所有列重荠，都必須依賴于主鍵箭阶，而不能有任何一列與主鍵沒有關(guān)系，也就是說一個表只描述一件事情戈鲁；
    • 第三范式：必須先滿足第二范式（2NF），要求：表中的每一列只與主鍵直接相關(guān)而不是間接相關(guān)嘹叫，（表中的每一列只能依賴于主鍵）婆殿；

MySQL

原理

InnoDB

優(yōu)化

索引

聚集索引, 非聚集索引

MyISAM 是非聚集罩扇，InnoDB 是聚集

復(fù)合索引

自適應(yīng)哈希索引(AHI)

explain

NoSQL

MongoDB

  • MongoDB 教程
  • 《Mongodb相對于關(guān)系型數(shù)據(jù)庫的優(yōu)缺點(diǎn)》
    • 優(yōu)點(diǎn)：弱一致性（最終一致）婆芦，更能保證用戶的訪問速度怕磨；內(nèi)置GridFS，支持大容量的存儲消约；Schema-less 數(shù)據(jù)庫肠鲫，不用預(yù)先定義結(jié)構(gòu)；內(nèi)置Sharding或粮；相比于其他NoSQL导饲，第三方支持豐富；性能優(yōu)越氯材；
    • 缺點(diǎn)：mongodb不支持事務(wù)操作渣锦；mongodb占用空間過大；MongoDB沒有如MySQL那樣成熟的維護(hù)工具氢哮，這對于開發(fā)和IT運(yùn)營都是個值得注意的地方袋毙；

Hbase

搜索引擎

搜索引擎原理

Lucene

Elasticsearch

Solr

sphinx

性能

性能優(yōu)化方法論

容量評估

CDN 網(wǎng)絡(luò)

連接池

性能調(diào)優(yōu)

大數(shù)據(jù)

流式計(jì)算

Storm

Flink

Kafka Stream

應(yīng)用場景

例如：

  • 廣告相關(guān)實(shí)時統(tǒng)計(jì)剩胁；
  • 推薦系統(tǒng)用戶畫像標(biāo)簽實(shí)時更新诉植；
  • 線上服務(wù)健康狀況實(shí)時監(jiān)測；
  • 實(shí)時榜單昵观；
  • 實(shí)時數(shù)據(jù)統(tǒng)計(jì)晾腔。

Hadoop

HDFS

MapReduce

Yarn

Spark

安全

web 安全

XSS

CSRF

SQL 注入

Hash Dos

腳本注入

漏洞掃描工具

驗(yàn)證碼

DDoS 防范

用戶隱私信息保護(hù)

  1. 用戶密碼非明文保存月洛，加動態(tài)salt何恶。
  2. 身份證號，手機(jī)號如果要顯示嚼黔，用 “*” 替代部分字符细层。
  3. 聯(lián)系方式在的顯示與否由用戶自己控制。
  4. TODO

序列化漏洞

加密解密

對稱加密

  • 《常見對稱加密算法》
    • DES碎节、3DES捧搞、Blowfish、AES
    • DES 采用 56位秘鑰狮荔，Blowfish 采用1到448位變長秘鑰胎撇，AES 128，192和256位長度的秘鑰殖氏。
    • DES 秘鑰太短（只有56位）算法目前已經(jīng)被 AES 取代晚树，并且 AES 有硬件加速，性能很好雅采。

哈希算法

非對稱加密

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

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

    • 和 RSA 不同的是 DSA 僅能用于數(shù)字簽名闰渔，不能進(jìn)行數(shù)據(jù)加密解密席函，其安全性和RSA相當(dāng)，但其性能要比RSA快冈涧。

    • 256位的ECC秘鑰的安全性等同于3072位的RSA秘鑰茂附。

      《區(qū)塊鏈的加密技術(shù)》

服務(wù)器安全

數(shù)據(jù)安全

數(shù)據(jù)備份

TODO

網(wǎng)絡(luò)隔離

內(nèi)外網(wǎng)分離

TODO

登錄跳板機(jī)

在內(nèi)外環(huán)境中通過跳板機(jī)登錄到線上主機(jī)。

授權(quán)督弓、認(rèn)證

RBAC

OAuth2.0

雙因素認(rèn)證（2FA）

2FA - Two-factor authentication营曼，用于加強(qiáng)登錄驗(yàn)證

常用做法是 登錄密碼 + 手機(jī)驗(yàn)證碼（或者令牌Key，類似于與網(wǎng)銀的 USB key）

單點(diǎn)登錄(SSO)

常用開源框架

開源協(xié)議

日志框架

Log4j愚隧、Log4j2

Logback

ORM

MyBatis：

網(wǎng)絡(luò)框架

TODO

Web 框架

Spring 家族

Spring

Spring Boot

Spring Cloud

工具框架

分布式設(shè)計(jì)

擴(kuò)展性設(shè)計(jì)

穩(wěn)定性 & 高可用

  • 《系統(tǒng)設(shè)計(jì)：關(guān)于高可用系統(tǒng)的一些技術(shù)方案》
    • 可擴(kuò)展：水平擴(kuò)展趟径、垂直擴(kuò)展瘪吏。 通過冗余部署，避免單點(diǎn)故障舵抹。
    • 隔離：避免單一業(yè)務(wù)占用全部資源肪虎。避免業(yè)務(wù)之間的相互影響 2. 機(jī)房隔離避免單點(diǎn)故障。
    • 解耦：降低維護(hù)成本惧蛹，降低耦合風(fēng)險扇救。減少依賴，減少相互間的影響香嗓。
    • 限流：滑動窗口計(jì)數(shù)法迅腔、漏桶算法、令牌桶算法等算法靠娱。遇到突發(fā)流量時沧烈，保證系統(tǒng)穩(wěn)定。
    • 降級：緊急情況下釋放非核心功能的資源像云。犧牲非核心業(yè)務(wù)锌雀，保證核心業(yè)務(wù)的高可用蚂夕。
    • 熔斷：異常情況超出閾值進(jìn)入熔斷狀態(tài)，快速失敗腋逆。減少不穩(wěn)定的外部依賴對核心服務(wù)的影響婿牍。
    • 自動化測試：通過完善的測試，減少發(fā)布引起的故障惩歉。
    • 灰度發(fā)布：灰度發(fā)布是速度與安全性作為妥協(xié)等脂，能夠有效減少發(fā)布故障。
  • 《關(guān)于高可用的系統(tǒng)》
    • 設(shè)計(jì)原則：數(shù)據(jù)不丟(持久化)撑蚌；服務(wù)高可用(服務(wù)副本)上遥；絕對的100%高可用很難，目標(biāo)是做到盡可能多的9争涌，如99.999%（全年累計(jì)只有5分鐘）粉楚。

硬件負(fù)載均衡

軟件負(fù)載均衡

限流

  • 《談?wù)劯卟l(fā)系統(tǒng)的限流》
    • 計(jì)數(shù)器：通過滑動窗口計(jì)數(shù)器否过，控制單位時間內(nèi)的請求次數(shù)，簡單粗暴李丰。
    • 漏桶算法：固定容量的漏桶苦锨，漏桶滿了就丟棄請求，比較常用。
    • 令牌桶算法：固定容量的令牌桶舟舒，按照一定速率添加令牌拉庶，處理請求前需要拿到令牌，拿不到令牌則丟棄請求魏蔗，或進(jìn)入丟隊(duì)列砍的，可以通過控制添加令牌的速率痹筛，來控制整體速度莺治。Guava 中的 RateLimiter 是令牌桶的實(shí)現(xiàn)。
    • Nginx 限流：通過 limit_req 等模塊限制并發(fā)連接數(shù)帚稠。

應(yīng)用層容災(zāi)

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

    • 雪崩效應(yīng)原因：硬件故障谣旁、硬件故障、程序Bug滋早、重試加大流量榄审、用戶大量請求。
    • 雪崩的對策：限流杆麸、改進(jìn)緩存模式(緩存預(yù)加載搁进、同步調(diào)用改異步)、自動擴(kuò)容昔头、降級饼问。
    • Hystrix設(shè)計(jì)原則：
      • 資源隔離：Hystrix通過將每個依賴服務(wù)分配獨(dú)立的線程池進(jìn)行資源隔離, 從而避免服務(wù)雪崩。
      • 熔斷開關(guān)：服務(wù)的健康狀況 = 請求失敗數(shù) / 請求總數(shù)揭斧，通過閾值設(shè)定和滑動窗口控制開關(guān)莱革。
      • 命令模式：通過繼承 HystrixCommand 來包裝服務(wù)調(diào)用邏輯。

  • 《緩存穿透讹开，緩存擊穿盅视，緩存雪崩解決方案分析》

  • 《緩存擊穿、失效以及熱點(diǎn)key問題》

    • 主要策略：失效瞬間：單機(jī)使用鎖旦万；使用分布式鎖闹击；不過期；
    • 熱點(diǎn)數(shù)據(jù)：熱點(diǎn)數(shù)據(jù)單獨(dú)存儲成艘；使用本地緩存赏半；分成多個子key；

跨機(jī)房容災(zāi)

  • 《“異地多活”多機(jī)房部署經(jīng)驗(yàn)談》

    • 通過自研中間件進(jìn)行數(shù)據(jù)同步狰腌。

  • 《異地多活（異地雙活）實(shí)踐經(jīng)驗(yàn)》

    • 注意延遲問題除破，多次跨機(jī)房調(diào)用會將延時放大數(shù)倍。
    • 建房間專線很大概率會出現(xiàn)問題琼腔，做好運(yùn)維和程序?qū)用娴娜蒎e瑰枫。
    • 不能依賴于程序端數(shù)據(jù)雙寫，要有自動同步方案。
    • 數(shù)據(jù)永不在高延遲和較差網(wǎng)絡(luò)質(zhì)量下光坝，考慮同步質(zhì)量問題尸诽。
    • 核心業(yè)務(wù)和次要業(yè)務(wù)分而治之，甚至只考慮核心業(yè)務(wù)盯另。
    • 異地多活監(jiān)控部署性含、測試也要跟上。
    • 業(yè)務(wù)允許的情況下考慮用戶分區(qū)鸳惯，尤其是游戲商蕴、郵箱業(yè)務(wù)。
    • 控制跨機(jī)房消息體大小芝发，越小越好绪商。
    • 考慮使用docker容器虛擬化技術(shù)，提高動態(tài)調(diào)度能力辅鲸。

  • 容災(zāi)技術(shù)及建設(shè)經(jīng)驗(yàn)介紹

容災(zāi)演練流程

平滑啟動

數(shù)據(jù)庫擴(kuò)展

讀寫分離模式

分片模式

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

    • 中間件： 輕量級：sharding-jdbc、TSharding叮姑；重量級：Atlas唉地、MyCAT据悔、Vitess等。
    • 問題：事務(wù)耘沼、Join极颓、遷移、擴(kuò)容群嗤、ID菠隆、分頁等。
    • 事務(wù)補(bǔ)償：對數(shù)據(jù)進(jìn)行對帳檢查;基于日志進(jìn)行比對;定期同標(biāo)準(zhǔn)數(shù)據(jù)來源進(jìn)行同步等狂秘。
    • 分庫策略：數(shù)值范圍骇径；取模；日期等赃绊。
    • 分庫數(shù)量：通常 MySQL 單庫 5千萬條既峡、Oracle 單庫一億條需要分庫。

  • 《MySql分表和表分區(qū)詳解》

    • 分區(qū)：是MySQL內(nèi)部機(jī)制碧查，對客戶端透明，數(shù)據(jù)存儲在不同文件中校仑，表面上看是同一個表忠售。
    • 分表：物理上創(chuàng)建不同的表、客戶端需要管理分表路由迄沫。

服務(wù)治理

服務(wù)注冊與發(fā)現(xiàn)

服務(wù)路由控制

  • 《分布式服務(wù)框架學(xué)習(xí)筆記4 服務(wù)路由》
    • 原則：透明化路由
    • 負(fù)載均衡策略：隨機(jī)、輪詢座韵、服務(wù)調(diào)用延遲险绘、一致性哈希、粘滯連接
    • 本地路由有限策略：injvm(優(yōu)先調(diào)用jvm內(nèi)部的服務(wù))，innative(優(yōu)先使用相同物理機(jī)的服務(wù)),原則上找距離最近的服務(wù)隆圆。
    • 配置方式：統(tǒng)一注冊表漱挚；本地配置；動態(tài)下發(fā)渺氧。

分布式一致

CAP 與 BASE 理論

  • 《從分布式一致性談到CAP理論旨涝、BASE理論》
    • 一致性分類：強(qiáng)一致(立即一致)；弱一致(可在單位時間內(nèi)實(shí)現(xiàn)一致侣背，比如秒級)白华；最終一致(弱一致的一種，一定時間內(nèi)最終一致)
    • CAP：一致性贩耐、可用性弧腥、分區(qū)容錯性(網(wǎng)絡(luò)故障引起)
    • BASE：Basically Available（基本可用）、Soft state（軟狀態(tài)）和Eventually consistent（最終一致性）
    • BASE理論的核心思想是：即使無法做到強(qiáng)一致性潮太，但每個應(yīng)用都可以根據(jù)自身業(yè)務(wù)特點(diǎn)管搪，采用適當(dāng)?shù)姆绞絹硎瓜到y(tǒng)達(dá)到最終一致性。

分布式鎖

  • 《分布式鎖的幾種實(shí)現(xiàn)方式》

    • 基于數(shù)據(jù)庫的分布式鎖：優(yōu)點(diǎn)：操作簡單铡买、容易理解更鲁。缺點(diǎn)：存在單點(diǎn)問題、數(shù)據(jù)庫性能夠開銷較大奇钞、不可重入澡为；
    • 基于緩存的分布式鎖：優(yōu)點(diǎn)：非阻塞、性能好景埃。缺點(diǎn)：操作不好容易造成鎖無法釋放的情況媒至。
    • Zookeeper 分布式鎖：通過有序臨時節(jié)點(diǎn)實(shí)現(xiàn)鎖機(jī)制，自己對應(yīng)的節(jié)點(diǎn)需要最小谷徙，則被認(rèn)為是獲得了鎖拒啰。優(yōu)點(diǎn)：集群可以透明解決單點(diǎn)問題，避免鎖不被釋放問題蒂胞，同時鎖可以重入图呢。缺點(diǎn)：性能不如緩存方式，吞吐量會隨著zk集群規(guī)模變大而下降骗随。

  • 《基于Zookeeper的分布式鎖》

    • 清楚的原理描述 + Java 代碼示例蛤织。

  • 《jedisLock—redis分布式鎖實(shí)現(xiàn)》

    • 基于 setnx(set if ont exists)，有則返回false鸿染，否則返回true指蚜。并支持過期時間。

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

    • 利用 memcached 的 add（有別于set）操作涨椒，當(dāng)key存在時摊鸡，返回false绽媒。

分布式一致性算法

PAXOS

Zab

Raft

Gossip

兩階段提交猎提、多階段提交

冪等

  • 《分布式系統(tǒng)---冪等性設(shè)計(jì)》
    • 冪等特性的作用：該資源具備冪等性锨苏，請求方無需擔(dān)心重復(fù)調(diào)用會產(chǎn)生錯誤疙教。
    • 常見保證冪等的手段：MVCC（類似于樂觀鎖）、去重表(唯一索引)伞租、悲觀鎖贞谓、一次性token桨嫁、序列號方式旺芽。

分布式一致方案

分布式 Leader 節(jié)點(diǎn)選舉

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

  • 《傳統(tǒng)事務(wù)與柔性事務(wù)》
    • 基于BASE理論：基本可用、柔性狀態(tài)楷掉、最終一致驯击。
    • 解決方案：記錄日志+補(bǔ)償（正向補(bǔ)充或者回滾）烁兰、消息重試(要求程序要冪等)；“無鎖設(shè)計(jì)”徊都、采用樂觀鎖機(jī)制。

分布式文件系統(tǒng)

唯一ID 生成

全局唯一ID

  • 《高并發(fā)分布式系統(tǒng)中生成全局唯一Id匯總》

    • Twitter 方案（Snowflake 算法）：41位時間戳+10位機(jī)器標(biāo)識（比如IP房轿，服務(wù)器名稱等）+12位序列號(本地計(jì)數(shù)器)
    • Flicker 方案：MySQL自增ID + "REPLACE INTO XXX:SELECT LAST_INSERT_ID();"
    • UUID：缺點(diǎn)，無序所森，字符串過長囱持，占用空間，影響檢索性能焕济。
    • MongoDB 方案：利用 ObjectId纷妆。缺點(diǎn)：不能自增。

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

    • 在數(shù)據(jù)庫中創(chuàng)建 sequence 表晴弃，用于記錄掩幢，當(dāng)前已被占用的id最大值逊拍。
    • 每臺客戶端主機(jī)取一個id區(qū)間（比如 1000~2000）緩存在本地，并更新 sequence 表中的id最大值記錄际邻。
    • 客戶端主機(jī)之間取不同的id區(qū)間芯丧，用完再取，使用樂觀鎖機(jī)制控制并發(fā)世曾。

一致性Hash算法

設(shè)計(jì)思想 & 開發(fā)模式

DDD(Domain-driven Design - 領(lǐng)域驅(qū)動設(shè)計(jì))

  • 《淺談我對DDD領(lǐng)域驅(qū)動設(shè)計(jì)的理解》

    • 概念：DDD 主要對傳統(tǒng)軟件開發(fā)流程(分析-設(shè)計(jì)-編碼)中各階段的割裂問題而提出缨恒，避免由于一開始分析不明或在軟件開發(fā)過程中的信息流轉(zhuǎn)不一致而造成軟件無法交付（和需求方設(shè)想不一致）的問題。DDD 強(qiáng)調(diào)一切以領(lǐng)域（Domain）為中心度硝，強(qiáng)調(diào)領(lǐng)域?qū)＜遥―omain Expert）的作用肿轨，強(qiáng)調(diào)先定義好領(lǐng)域模型之后在進(jìn)行開發(fā)，并且領(lǐng)域模型可以指導(dǎo)開發(fā)（所謂的驅(qū)動）蕊程。
    • 過程：理解領(lǐng)域椒袍、拆分領(lǐng)域、細(xì)化領(lǐng)域藻茂，模型的準(zhǔn)確性取決于模型的理解深度驹暑。
    • 設(shè)計(jì)：DDD 中提出了建模工具，比如聚合辨赐、實(shí)體优俘、值對象、工廠掀序、倉儲帆焕、領(lǐng)域服務(wù)、領(lǐng)域事件來幫助領(lǐng)域建模不恭。

  • 《領(lǐng)域驅(qū)動設(shè)計(jì)的基礎(chǔ)知識總結(jié)》

    • 領(lǐng)域（Doamin）本質(zhì)上就是問題域叶雹，比如一個電商系統(tǒng)，一個論壇系統(tǒng)等换吧。
    • 界限上下文（Bounded Context）：闡述子域之間的關(guān)系折晦，可以簡單理解成一個子系統(tǒng)或組件模塊。
    • 領(lǐng)域模型（Domain Model）：DDD的核心是建立（用通用描述語言沾瓦、工具—領(lǐng)域通用語言）正確的領(lǐng)域模型满着；反應(yīng)業(yè)務(wù)需求的本質(zhì)，包括實(shí)體和過程贯莺；其貫穿軟件分析风喇、設(shè)計(jì)、開發(fā) 的整個過程乖篷；常用表達(dá)領(lǐng)域模型的方式：圖响驴、代碼或文字；
    • 領(lǐng)域通用語言：領(lǐng)域?qū)＜宜喊㈤_發(fā)設(shè)計(jì)人員都能立即的語言或工具豁鲤。
    • 經(jīng)典分層架構(gòu)：用戶界面/展示層秽誊、應(yīng)用層、領(lǐng)域?qū)恿章狻⒒A(chǔ)設(shè)施層锅论，是四層架構(gòu)模式。
    • 使用的模式：
      • 關(guān)聯(lián)盡量少楣号，盡量單項(xiàng)最易，盡量降低整體復(fù)雜度。
      • 實(shí)體（Entity）：領(lǐng)域中的唯一標(biāo)示炫狱，一個實(shí)體的屬性盡量少藻懒，少則清晰。
      • 值對象（Value Object）：沒有唯一標(biāo)識视译，且屬性值不可變嬉荆，小二簡單的對象，比如Date酷含。
      • 領(lǐng)域服務(wù)（Domain Service）： 協(xié)調(diào)多個領(lǐng)域?qū)ο蟊稍纾挥蟹椒]有狀態(tài)(不存數(shù)據(jù))；可以分為應(yīng)用層服務(wù)椅亚，領(lǐng)域?qū)臃?wù)限番、基礎(chǔ)層服務(wù)。
      • 聚合及聚合根（Aggregate呀舔，Aggregate Root）：聚合定義了一組具有內(nèi)聚關(guān)系的相關(guān)對象的集合弥虐；聚合根是對聚合引用的唯一元素；當(dāng)修改一個聚合時媚赖，必須在事務(wù)級別躯舔；大部分領(lǐng)域模型中，有70%的聚合通常只有一個實(shí)體省古，30%只有2~3個實(shí)體；如果一個聚合只有一個實(shí)體丧失，那么這個實(shí)體就是聚合根豺妓；如果有多個實(shí)體，那么我們可以思考聚合內(nèi)哪個對象有獨(dú)立存在的意義并且可以和外部直接進(jìn)行交互布讹；
      • 工廠（Factory）：類似于設(shè)計(jì)模式中的工廠模式琳拭。
      • 倉儲（Repository）：持久化到DB，管理對象描验，且只對聚合設(shè)計(jì)倉儲白嘁。

  • 《領(lǐng)域驅(qū)動設(shè)計(jì)(DDD)實(shí)現(xiàn)之路》

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

  • 《領(lǐng)域驅(qū)動設(shè)計(jì)系列（2）淺析VO鲁沥、DTO、DO耕魄、PO的概念画恰、區(qū)別和用處》

命令查詢職責(zé)分離(CQRS)

CQRS — Command Query Responsibility Seperation

貧血糊治，充血模型

  • 《貧血，充血模型的解釋以及一些經(jīng)驗(yàn)》
    • 失血模型：老子和兒子分別定義档泽，相互不知道俊戳，二者實(shí)體定義中完全沒有業(yè)務(wù)邏輯，通過外部Service進(jìn)行關(guān)聯(lián)馆匿。
    • 貧血模型：老子知道兒子抑胎，兒子也知道老子；部分業(yè)務(wù)邏輯放到實(shí)體中渐北；優(yōu)點(diǎn)：各層單項(xiàng)依賴阿逃，結(jié)構(gòu)清楚，易于維護(hù)赃蛛；缺點(diǎn)：不符合OO思想恃锉，相比于充血模式，Service層較為厚重呕臂；
    • 充血模型：和貧血模型類似破托，區(qū)別在于如何劃分業(yè)務(wù)邏輯。優(yōu)點(diǎn)：Service層比較薄歧蒋，只充當(dāng)Facade的角色土砂，不和DAO打交道、復(fù)合OO思想谜洽；缺點(diǎn)：非單項(xiàng)依賴萝映，DO和DAO之間雙向依賴、和Service層的邏輯劃分容易造成混亂阐虚。
    • 腫脹模式：是一種極端情況序臂，取消Service層、全部業(yè)務(wù)邏輯放在DO中实束；優(yōu)點(diǎn)：符合OO思想奥秆、簡化了分層逊彭；缺點(diǎn)：暴露信息過多、很多非DO邏輯也會強(qiáng)行并入DO吭练。這種模式應(yīng)該避免诫龙。
    • 作者主張使用貧血模式。

Actor 模式

TODO

響應(yīng)式編程

Reactor

TODO

RxJava

TODO

Vert.x

TODO

DODAF2.0

Serverless

無需過多關(guān)系服務(wù)器的服務(wù)架構(gòu)理念鲫咽。

  • 《什么是Serverless無服務(wù)器架構(gòu)签赃？》

    • Serverless 不代表出去服務(wù)器，而是去除對服務(wù)器運(yùn)行狀態(tài)的關(guān)心分尸。
    • Serverless 代表一思維方式的轉(zhuǎn)變锦聊，從“構(gòu)建一套服務(wù)在一臺服務(wù)器上，對對個事件進(jìn)行響應(yīng)轉(zhuǎn)變?yōu)闃?gòu)建一個為服務(wù)器箩绍，來響應(yīng)一個事件”孔庭。
    • Serverless 不代表某個具體的框架。

  • 《如何理解Serverless材蛛？》

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

Service Mesh

項(xiàng)目管理

架構(gòu)評審

重構(gòu)

代碼規(guī)范

TODO

代碼 Review

制度還是制度!
另外卑吭，每個公司需要根據(jù)自己的需求和目標(biāo)制定自己的 check list

RUP

看板管理

SCRUM

SCRUM - 爭球

  • 3個角色:Product Owner(PO) 產(chǎn)品負(fù)責(zé)人;Scrum Master（SM）挣菲，推動Scrum執(zhí)行;Team 開發(fā)團(tuán)隊(duì)。
  • 3個工件：Product Backlog 產(chǎn)品TODOLIST掷邦，含優(yōu)先級;Sprint Backlog 功能開發(fā) TODO LIST白胀；燃盡圖；
  • 五個價值觀：專注抚岗、勇氣或杠、公開、承諾宣蔚、尊重廷痘。

敏捷開發(fā)

TODO

極限編程（XP）

XP - eXtreme Programming

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

    • 是一種指導(dǎo)開發(fā)人員的方法論件已。

    • 4大價值：

      • 溝通：鼓勵口頭溝通，提高效率元暴。
      • 簡單：夠用就好篷扩。
      • 反饋：及時反饋、通知相關(guān)人茉盏。
      • 勇氣：提倡擁抱變化，敢于重構(gòu)。

    • 5個原則：快速反饋评架、簡單性假設(shè)墙歪、逐步修改、提倡更改（小步快跑）为障、優(yōu)質(zhì)工作（保證質(zhì)量的前提下保證小步快跑）。

    • 5個工作：階段性沖刺；沖刺計(jì)劃會議核蘸；每日站立會議；沖刺后review啸驯；回顧會議客扎。

結(jié)對編程

邊寫碼，邊review罚斗。能夠增強(qiáng)代碼質(zhì)量徙鱼、減少bug。

PDCA 循環(huán)質(zhì)量管理

P——PLAN 策劃针姿，D——DO 實(shí)施袱吆，C——CHECK 檢查，A——ACT 改進(jìn)

FMEA管理模式

TODO

通用業(yè)務(wù)術(shù)語

TODO

技術(shù)趨勢

TODO

政策距淫、法規(guī)

TODO

法律

嚴(yán)格遵守刑法253法條

我國刑法第253條之一規(guī)定：

  • 國家機(jī)關(guān)或者金融绞绒、電信、交通溉愁、教育处铛、醫(yī)療等單位的工作人員，違反國家規(guī)定拐揭，將本單位在履行職責(zé)或者提供服務(wù)過程中獲得的公民個人信息撤蟆，出售或者非法提供給他人，情節(jié)嚴(yán)重的堂污，處3年以下有期徒刑或者拘役家肯，并處或者單處罰金。
  • 竊取或者以其他方法非法獲取上述信息盟猖，情節(jié)嚴(yán)重的讨衣，依照前款的規(guī)定處罰。
  • 單位犯前兩款罪的式镐，對單位判處罰金反镇，并對其直接負(fù)責(zé)的主管人員和其他直接責(zé)任人員，依照各該款的規(guī)定處罰娘汞。

最高人民法院歹茶、最高人民檢察院關(guān)于執(zhí)行《中華人民共和國刑法》確定罪名的補(bǔ)充規(guī)定（四）規(guī)定：觸犯刑法第253條之一第1款之規(guī)定，構(gòu)成“出售、非法提供公民個人信息罪”惊豺；觸犯刑法第253條之一第2款之規(guī)定燎孟，構(gòu)成“非法獲取公民個人信息罪”

架構(gòu)師素質(zhì)

  • 《架構(gòu)師畫像》

    • 業(yè)務(wù)理解和抽象能力
    • NB的代碼能力
    • 全面：1. 在面對業(yè)務(wù)問題上，架構(gòu)師腦海里是否會浮現(xiàn)出多種技術(shù)方案尸昧；2. 在做系統(tǒng)設(shè)計(jì)時是否考慮到了足夠多的方方面面揩页；3. 在做系統(tǒng)設(shè)計(jì)時是否考慮到了足夠多的方方面面；
    • 全局：是否考慮到了對上下游的系統(tǒng)的影響烹俗。
    • 權(quán)衡：權(quán)衡投入產(chǎn)出比爆侣；優(yōu)先級和節(jié)奏控制；

  • 《關(guān)于架構(gòu)優(yōu)化和設(shè)計(jì)衷蜓，架構(gòu)師必須知道的事情》

    • 要去考慮的細(xì)節(jié)：模塊化累提、輕耦合、無共享架構(gòu)磁浇；減少各個組件之前的依賴斋陪、注意服務(wù)之間依賴所有造成的鏈?zhǔn)绞〖坝绊懙取?/li>
    • 基礎(chǔ)設(shè)施、配置置吓、測試无虚、開發(fā)、運(yùn)維綜合考慮衍锚。
    • 考慮人友题、團(tuán)隊(duì)、和組織的影響戴质。

  • 《如何才能真正的提高自己度宦，成為一名出色的架構(gòu)師？》

  • 《架構(gòu)師的必備素質(zhì)和成長途徑》

    • 素質(zhì)：業(yè)務(wù)理解告匠、技術(shù)廣度戈抄、技術(shù)深度、豐富經(jīng)驗(yàn)后专、溝通能力划鸽、動手能力、美學(xué)素養(yǎng)戚哎。
    • 成長路徑：2年積累知識裸诽、4年積累技能和組內(nèi)影響力、7年積累部門內(nèi)影響力型凳、7年以上積累跨部門影響力丈冬。

  • 《架構(gòu)設(shè)計(jì)師—你在哪層樓？》

    • 第一層的架構(gòu)師看到的只是產(chǎn)品本身
    • 第二層的架構(gòu)師不僅看到自己的產(chǎn)品甘畅，還看到了整體的方案
    • 第三層的架構(gòu)師看到的是商業(yè)價值

團(tuán)隊(duì)管理

TODO

招聘

資訊

行業(yè)資訊

公眾號列表

TODO

博客

團(tuán)隊(duì)博客

個人博客

綜合門戶殷蛇、社區(qū)

國內(nèi)：

國外：

問答泄朴、討論類社區(qū)

行業(yè)數(shù)據(jù)分析

專項(xiàng)網(wǎng)站

其他類

推薦參考書

在線電子書

紙質(zhì)書

開發(fā)方面

架構(gòu)方面

  • 《軟件架構(gòu)師的12項(xiàng)修煉：技術(shù)技能篇》京東 淘寶

  • 《架構(gòu)之美》京東 淘寶

  • 《分布式服務(wù)架構(gòu)》京東 淘寶

  • 《聊聊架構(gòu)》 京東 淘寶

  • 《云原生應(yīng)用架構(gòu)實(shí)踐》京東 淘寶

  • 《億級流量網(wǎng)站架構(gòu)核心技術(shù)》京東 淘寶

  • 《淘寶技術(shù)這十年》京東 淘寶

  • 《企業(yè)IT架構(gòu)轉(zhuǎn)型之道-中臺戰(zhàn)略思想與架構(gòu)實(shí)戰(zhàn)》 京東 淘寶

  • 《高可用架構(gòu)（第1卷）》京東 淘寶

技術(shù)管理方面

  • 《CTO說》京東 淘寶
  • 《技術(shù)管理之巔》京東 淘寶
  • 《網(wǎng)易一千零一夜：互聯(lián)網(wǎng)產(chǎn)品項(xiàng)目管理實(shí)戰(zhàn)》京東 淘寶

基礎(chǔ)理論

工具方面

TODO

大數(shù)據(jù)方面

技術(shù)資源

開源資源

手冊祖灰、文檔、教程

國內(nèi)：

  • W3Cschool

  • Runoob.com

    • HTML 畔规、 CSS局扶、XML、Java叁扫、Python三妈、PHP、設(shè)計(jì)模式等入門手冊莫绣。

  • Love2.io

    • 很多很多中文在線電子書畴蒲，是一個全新的開源技術(shù)文檔分享平臺。

  • gitbook.cn

    • 付費(fèi)電子書对室。

  • ApacheCN

    • AI模燥、大數(shù)據(jù)方面系列中文文檔。

國外：

  • Quick Code
    • 免費(fèi)在線技術(shù)教程掩宜。
  • gitbook.com
    • 有部分中文電子書蔫骂。
  • Cheatography
    • Cheat Sheets 大全，單頁文檔網(wǎng)站锭亏。
  • Tutorialspoint
    • 知名教程網(wǎng)站纠吴，提供Java、Python慧瘤、JS戴已、SQL、大數(shù)據(jù)等高質(zhì)量入門教程锅减。

在線課堂

會議、活動

活動發(fā)布平臺:

常用APP

找工作

工具

代碼托管

文件服務(wù)

  • 七牛
  • 又拍云

綜合云服務(wù)商

VPS

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 人面猴
    序言：七十年代末握联，一起剝皮案震驚了整個濱河市桦沉，隨后出現(xiàn)的幾起案子，更是在濱河造成了極大的恐慌金闽，老刑警劉巖纯露，帶你破解...
    沈念sama閱讀 218,682評論 6贊 507
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件，死亡現(xiàn)場離奇詭異代芜，居然都是意外死亡埠褪，警方通過查閱死者的電腦和手機(jī)，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 93,277評論 3贊 395
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進(jìn)店門挤庇，熙熙樓的掌柜王于貴愁眉苦臉地迎上來钞速，“玉大人，你說我怎么就攤上這事嫡秕】视铮” “怎么了？”我有些...
    開封第一講書人閱讀 165,083評論 0贊 355
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵昆咽，是天一觀的道長驾凶。 經(jīng)常有香客問我，道長潮改，這世上最難降的妖魔是什么狭郑？ 我笑而不...
    開封第一講書人閱讀 58,763評論 1贊 295
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任，我火速辦了婚禮汇在，結(jié)果婚禮上翰萨，老公的妹妹穿的比我還像新娘。我一直安慰自己糕殉，他們只是感情好亩鬼，可當(dāng)我...
    茶點(diǎn)故事閱讀 67,785評論 6贊 392
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布。 她就那樣靜靜地躺著阿蝶，像睡著了一般雳锋。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上羡洁，一...
    開封第一講書人閱讀 51,624評論 1贊 305
  • 城市分裂傳說
    那天玷过，我揣著相機(jī)與錄音，去河邊找鬼筑煮。 笑死辛蚊，一個胖子當(dāng)著我的面吹牛，可吹牛的內(nèi)容都是我干的真仲。 我是一名探鬼主播袋马，決...
    沈念sama閱讀 40,358評論 3贊 418
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼，長吁一口氣：“原來是場噩夢啊……” “哼秸应！你這毒婦竟也來了虑凛？” 一聲冷哼從身側(cè)響起碑宴，我...
    開封第一講書人閱讀 39,261評論 0贊 276
  • 萬榮殺人案實(shí)錄
    序言：老撾萬榮一對情侶失蹤，失蹤者是張志新（化名）和其女友劉穎桑谍，沒想到半個月后延柠，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體，經(jīng)...
    沈念sama閱讀 45,722評論 1贊 315
  • ?護(hù)林員之死
    正文 獨(dú)居荒郊野嶺守林人離奇死亡锣披，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 37,900評論 3贊 336
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年捕仔，在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片盈罐。...
    茶點(diǎn)故事閱讀 40,030評論 1贊 350
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡，死狀恐怖闪唆，靈堂內(nèi)的尸體忽然破棺而出盅粪，到底是詐尸還是另有隱情，我是刑警寧澤悄蕾，帶...
    沈念sama閱讀 35,737評論 5贊 346
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布票顾，位于F島的核電站，受9級特大地震影響帆调，放射性物質(zhì)發(fā)生泄漏奠骄。R本人自食惡果不足惜，卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 41,360評論 3贊 330
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一番刊、第九天 我趴在偏房一處隱蔽的房頂上張望含鳞。 院中可真熱鬧，春花似錦芹务、人聲如沸蝉绷。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,941評論 0贊 22
  • 一樁弒父案枣抱，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽熔吗。三九已至，卻和暖如春佳晶，著一層夾襖步出監(jiān)牢的瞬間桅狠，已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 33,057評論 1贊 270
  • 情欲美人皮
    我被黑心中介騙來泰國打工轿秧， 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留中跌，地道東北人。 一個月前我還...
    沈念sama閱讀 48,237評論 3贊 371
  • 代替公主和親
    正文 我出身青樓淤刃，卻偏偏與公主長得像晒他，于是被迫代替她去往敵國和親博烂。 傳聞我的和親對象是個殘疾皇子亮蛔，可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 44,976評論 2贊 355

推薦閱讀更多精彩內(nèi)容