1.技術選型

1.什么是技術選型？

技術選型是指評估和選擇在項目或系統開發中使用的最合適的技術和工具的過程。這涉及考慮基于其能力、特性、與項目需求的兼容性、可擴展性、性能、維護和其他因素的各種可用選項。技術選型的目標是確定與項目目標相符合、能夠有效解決項目挑戰和目標的最佳技術。

技術選型的過程通常包括：

項目評估：了解項目的目標、需求、約束和范圍，以確定需要哪些技術。

研究：對不同技術、框架和工具進行徹底的研究，以滿足項目的潛在需求。

比較：評估每種技術選項的優勢和劣勢，考慮功能、性能、社區支持、可擴展性、安全性和成本等因素。

概念驗證：構建原型或進行小規模實驗，以驗證在項目中使用特定技術的可行性。

風險分析：識別與每個技術選擇相關的潛在風險，包括兼容性問題、學習曲線、廠商依賴性和未來支持等。

專家咨詢：尋求對所考慮技術有經驗的專家、同事或行業專業人士的建議。

長期可行性：評估所選技術的長期可行性和未來增長潛力，以確保其能夠在一段時間內保持相關性和支持。

成本考慮：評估實施和維護所選技術的初期和長期成本。

反饋與迭代：在選型過程中融入利益相關者、開發人員和用戶的反饋，以確保與其需求保持一致。

決策：基于對選項及其影響的全面理解做出明智的決策。

有效的技術選型至關重要，因為技術選擇可以顯著影響項目的成功。恰當選擇的技術可以簡化開發流程、提高性能、改善用戶體驗并促進長期維護。另一方面，糟糕的技術選型可能導致項目延遲、增加成本、兼容性問題甚至項目失敗。因此投入時間和精力進行研究、比較和選擇合適的技術是實現成功項目成果的基本步驟。

2.為什么要技術選型？

技術選型的重要性體現在以下幾個方面：

1. 滿足項目需求： 不同的項目有不同的需求和目標。技術選型可以確保所選的技術和工具能夠滿足項目的功能、性能、安全性和可擴展性等需求。
2. 提高開發效率： 選擇合適的技術可以加快開發過程，減少開發人員的工作量。適合項目的技術能夠提供更多的開發工具、庫和框架，從而簡化開發流程。
3. 優化性能： 不同技術在性能方面有所差異。選擇性能良好的技術可以確保項目具有快速的響應時間和高效的運行。
4. 降低風險： 經過充分的調研和驗證后，選擇合適的技術可以降低項目失敗的風險。避免了可能的技術問題和不穩定性。
5. 適應未來發展： 選用能夠適應未來技術發展的技術，可以延長項目的壽命并減少技術遷移的成本。
6. 提高用戶體驗： 選擇適合項目的技術可以提供更好的用戶體驗，包括更快的加載時間、友好的界面和響應式設計等。
7. 降低成本： 正確選擇技術可以減少項目開發和維護的成本。合適的技術可以減少不必要的資源浪費。
8. 避免廠商鎖定： 在技術選型時，考慮到技術的開放性和廠商支持，可以避免在未來被特定供應商限制。
9. 可維護性： 選擇易于維護的技術可以確保項目在長期內保持穩定和可維護。
10. 支持社區： 選擇有活躍社區的技術可以獲得更多支持、文檔和解決問題的資源。

綜上所述，技術選型是項目成功的關鍵因素之一。通過仔細考慮項目需求、調研不同的選項、驗證適合性并做出明智的決策，可以確保項目在開發、上線和維護過程中取得更好的成果。

3.技術選型案例

跨境電商企業在技術選型時選擇了Service Mesh Istio，但是在沒有經過充分調研和驗證的情況下，直接在開發環境中部署。這導致了一系列問題，包括項目延遲和長時間的適應期，最終影響了項目的正式上線。

從中提取出了一些重要的教訓：

1. 充分調研： 在決定采用新技術之前，進行充分的調研，了解技術的特點、優勢、劣勢以及適用場景。不要輕率地選擇技術，而是確保它能夠滿足項目需求。
2. 小規模嘗試： 在大規模采用之前，嘗試在小規模環境中引入新技術。這有助于發現潛在問題、了解技術的運作方式，并在實踐中積累經驗。
3. 驗證和適應期： 對于新技術，預留一段適應期是很重要的。技術的實際表現可能與預期不同，因此給予項目團隊足夠的時間來適應和解決問題是必要的。
4. 項目風險： 技術選型不僅需要考慮技術本身的特點，還需要考慮其可能引發的項目風險。不穩定的技術可能導致項目延遲、成本增加等問題。
5. 經驗積累： 通過小規模引入和驗證，項目團隊可以積累關于技術的經驗，了解如何優化和解決潛在問題。

綜合來看，這個案例強調了在技術選型中謹慎而有計劃的重要性。不要急于采納新技術，而是通過調研、驗證和小規模試驗來確保技術能夠穩定地支持項目的成功實施。

2.系統設計方法

1. 前端

2. 后端

3. API gateway網關架構

4. 7種分布式系統設計模式

5. 6種API架構風格

6. 常見應用架構模式

7. api安全的12個要點

8. 提升api性能的7中方法

9. 系統設計應遵循的原則

10. Redis常見用法

11. 25篇經典分布式架構設計論文

12.DevOps&SRE

13. 5種部署方法

3.微服務架構方法

1.微服務架構設計理論

1.NFR(非功能性需求)：

2.架構的構成元素：

3.軟件架構的4+1視圖模型

4.編寫FTGO應用架構文檔案例

4+1視圖架構：

架構愿景（vision）

系統上下文

架構涉及的核心用戶故事和場景

非功能性需求：

編寫服務清單文檔

編寫服務領域模型文檔

記錄架構決策

總結

2.微服務設計模式

4.云原生架構要點

0.架構演進的過程

1.云原生應用設計的12個要素

基準代碼：指代碼版本管理，基于同一個版本代碼開發

依賴：顯式的依賴

配置：代碼與環境配置分開

進程：應用以一個或多個進程進行運行，應用無狀態

端口綁定：端口與服務綁定

日志：日志以事件流的形式來看，方便處理

2. 云原生架構

3.下一代云原生架構serviceMesh(服務網格化)

微服務與Service Mesh 的區別和聯系：

4.Docker

Docker原理

5.k8s

k8s架構

5.參考資料

• 《微服務架構設計模式》 & 代碼： https://github.com/microservices-patterns/ftgo-application
• 微服務理論網站：
  https://microservices.io/
  https://eventuate.io/