【成爲架構師1-2】技術選型：框架組件要不要自研，何時自研

系列文章是博主對沈劍的《架構師訓練營》分享內容的個人筆記總結，原內容公衆號“成爲架構師”。

1 早期不建議自研

1. 早期，業務以“快速迭代”爲最高優先級
2. 技術棧，以自己熟悉的爲選型依據
3. 此時，對技術合夥人的視野有一定要求

2 控制技術棧的統一

1. 絕對不能，每個人想用什麼就用什麼
2. 即使是開源，技術棧也要儘量統一

團隊之間不統一的技術棧必然造成開發、測試、運維成本的鉅額提高，且必將造成混亂

以下是我自己的一點感觸：技術棧統一聽上去是一個很簡單也十分基礎的要求，大家作爲一個團隊一起開發，使用相同的技術框架似乎是理所當然的。就我自己而言，我所處的團隊規模還非常的小，技術棧不統一這一點卻不僅發生在成員之間還發生在自己身上。或許這聽起來匪夷所思，爲什麼自己使用的技術棧都會不一樣，這個不一樣表現在一個開發週期內的時間尺度上，我總是傾向於使用業內更成熟、更高效的技術框架，但原先的項目是以舊的技術框架爲基礎的，在沒有大規模的重構之前，不合理地引入部分新技術造成了衝擊，而新技術實際帶來的收益（開發效率、成品性能）並不足以彌補造成的損失。且這對於未來重構也未必能起到好的作用。

3 對第三方庫“淺淺地封裝一層”

1. 何爲“淺淺地封裝一層”

// Memcache的原API
String Memcache::get(String key)

// 向調用方暴露的API
String 58DaojiaKV::get(String key) {
	String result = Memcache::get(key);
	return result;
}

上述封裝看上去只是命名空間的變化，但其實這一封裝首先有兩點封裝的通用優勢：

1. 對使用方屏蔽實現細節
2. 底層變化時，調用方改動很小（如Memcache變化爲Redis，調用方只需要升級依賴的 58DaojiaKV 這一庫即可）
3. 能夠方便實現統一的功能，爲後續的擴展預留空間

在開發初期，並不能識別所有的業務需求和非功能性需求，這一層淺淺的封裝就爲後續的擴展預留了空間，比如說要記錄緩存的訪問時間：

String 58DaojiaKV::get(String key) {
	Long startTime = now();
	String result = Memcache::get(key);
	Long endTime = now();
	reportKVTime(startTime - endTime);
	return result;
}

當然上述只是一個例子，像這類公共的記錄可以從全局去處理，比如做切面等等。

4 在後期，適當地造一些輪子

爲什麼無法全部使用開源：開源解決不了全部的個性化需求

造輪子的可能性：不同的技術團隊，痛點是相似的

自研解決痛點，更貼合團隊的實際

---

下一篇開始將進入增長期，流量百萬級別的架構設計，討論關於容量設計的話題，並如何進行容量預估。

上一篇回顧：【成爲架構師1-1】技術選型：創業初期，技術如何選型
下一篇更精彩：【成爲架構師2-1】容量設計：流量高低，對架構究竟有什麼影響