分布式架構
分布式應用架構中，相互獨立，**獨立開發，獨立部署，通過api介面互相通訊。通訊協議一般使用http，資料格式是json(是一種輕量級的資料交換格式)，應用整合方式比較簡化。
優點: 應用內部高內聚，獨立開發、測試和部署，應用之間松耦合，業務邊界清晰，業務依賴明確，支援大專案並行開發。
缺點: api介面需求變化，應用就需要重新部署，通訊可靠性和資料的封裝性相對於程序內呼叫比較差。
soa架構[現在也流程saas服務模式架構也稱雲架構]
soa也是分布式應用架構一種。
soa架構提供配套的服務治理，包括服務註冊、服務路由、服務授權、服務降級、服務監控等等。
soa架構既體現業務的拆分，又體現業務的整合，更多地從業務整體上考慮系統拆分。
優點：以服務層為主，聚焦核心業務，同時以提供整個系統共享，服務作為獨立的應用，獨立部署，介面清晰，很容易做自動化測試和部署，服務是無狀態的，很容易做水平擴充套件；通過容器虛擬化技術，實現故障隔離和資源高效利用。
缺點：系統依賴複雜，給開發/測試/部署帶來不便，分布式資料一致性和分布式事務支援困難，一般通過最終一致性簡化解決。
單體式應用
系統只有乙個應用、打包成乙個應用；部署在一台機器；在乙個db裡儲存資料.
單體式應用採用分層架構，一般為表示層、業務層、資料訪問層、db層，表示層負責使用者體驗，業務層負責業務邏輯，資料訪問層負責db層的資料訪問
優點：開發、編譯、除錯一站式、乙個應用程式包含所有功能點，容易測試和部署
缺點：系統逐漸龐大時，**複雜度高，難以維護，應用擴充套件水平低，業務和模組職責區分不清晰。
微服務架構
微服務架構（microservices architecture）是服務導向架構（service-oriented architecture，縮寫 soa）的公升級。
每乙個服務就是乙個獨立的部署單元（separately deployed unit）。這些單元都是分布式的，互相解耦，通過遠端通訊協議（比如rest、soap）聯絡。
微服務架構分成三種實現模式。
restful api 模式：服務通過 api 提供，雲服務就屬於這一類
restful 應用模式：服務通過傳統的網路協議或者應用協議提供，背後通常是乙個多功能的應用程式，常見於企業內部
集中訊息模式
：採用訊息**（message broker），可以實現訊息佇列、負載均衡、統一日誌和異常處理，缺點是會出現單點失敗，訊息**可能要做成集群
優點擴充套件性好，各個服務之間低耦合
容易部署，軟體從單一可部署單元，被拆成了多個服務，每個服務都是可部署單元
容易開發，每個元件都可以進行持續整合式的開發，可以做到實時部署，不間斷地公升級
易於測試，可以單獨測試每乙個服務
缺點由於強調互相獨立和低耦合，服務可能會拆分得很細。這導致系統依賴大量的微服務，變得很凌亂和笨重，效能也會不佳。
一旦服務之間需要通訊（即乙個服務要用到另乙個服務），整個架構就會變得複雜。典型的例子就是一些通用的 utility 類，一種解決方案是把它們拷貝到每乙個服務中去，用冗餘換取架構的簡單性。
分布式的本質使得這種架構很難實現原子性操作，交易回滾會比較困難。
事件驅動架構
事件（event）是狀態發生變化時，軟體發出的通知。
事件驅動架構（event-driven architecture）就是通過事件進行通訊的軟體架構。它分成四個部分。
事件佇列（event queue）：接收事件的入口。
分發器（event mediator）：將不同的事件分發到不同的業務邏輯單元。
事件通道（event channel）：分發器與處理器之間的聯絡渠道。
事件處理器（event processor）：實現業務邏輯，處理完成後會發出事件，觸發下一步操作
對於簡單的專案，事件佇列、分發器和事件通道，可以合為一體，整個軟體就分成事件**和事件處理器兩部分。
優點分布式的非同步架構，事件處理器之間高度解耦，軟體的擴充套件性好；適用性廣，各種型別的專案都可以用；效能較好，因為事件的非同步本質，軟體不易產生堵塞；事件處理器可以獨立地載入和解除安裝，容易部署
缺點涉及非同步程式設計（要考慮遠端通訊、失去響應等情況），開發相對複雜難以支援原子性操作，因為事件通過會涉及多個處理器，很難回滾分布式和非同步特性導致這個架構較難測試。
分層架構。
分層架構（layered architecture）是最常見的軟體架構，也是事實上的標準架構。如果你不知道要用什麼架構，那就用它。
這種架構將軟體分成若干個水平層，每一層都有清晰的角色和分工，不需要知道其他層的細節。層與層之間通過介面通訊。
雖然沒有明確約定，軟體一定要分成多少層，但是四層的結構最常見。
表現層（presentation）：使用者介面，負責視覺和使用者互動。
業務層（business）：實現業務邏輯。
持久層（persistence）：提供資料，sql 語句就放在這一層。
資料庫（database） ：儲存資料。
有的軟體在邏輯層和持久層之間，加了乙個服務層（service），提供不同業務邏輯需要的一些通用介面。
使用者的請求將依次通過這四層的處理，不能跳過其中任何一層。
優點1、結構簡單，容易理解和開發。
2、不同技能的程式設計師可以分工，負責不同的層，天然適合大多數軟體公司的組織架構
3、每一層都可以獨立測試，其他層的介面通過模擬解決
缺點1、一旦環境變化，需要**調整或增加功能時，通常比較麻煩和費時
2、部署比較麻煩，即使只修改乙個小地方，往往需要整個軟體重新部署，不容易做持續發布
軟體公升級時，可能需要整個服務暫停
3、擴充套件性差。使用者請求大量增加時，必須依次擴充套件每一層，由於每一層內部是耦合的，擴充套件會很困難。
微核架構。
微核架構（microkernel architecture）又稱為"外掛程式架構"（plug-in architecture），指的是軟體的核心相對較小，主要功能和業務邏輯都通過外掛程式實現。
核心（core）通常只包含系統執行的最小功能。外掛程式則是互相獨立的，外掛程式之間的通訊，應該減少到最低，避免出現互相依賴的問題。
優點1、良好的功能延伸性（extensibility），需要什麼功能，開發乙個外掛程式即可
2、功能之間是隔離的，外掛程式可以獨立的載入和解除安裝，使得它比較容易部署，
3、可定製性高，適應不同的開發需要
4、可以漸進式地開發，逐步增加功能
缺點1、擴充套件性（scalability）差，核心通常是乙個獨立單元，不容易做成分布式
2、開發難度相對較高，因為涉及到外掛程式與核心的通訊，以及內部的外掛程式登記機制。
雲架構。
雲結構（cloud architecture）主要解決擴充套件性和併發的問題，是最容易擴充套件的架構。
它的高擴充套件性，主要原因是沒使用**資料庫，而是把資料都複製到記憶體中，變成可複製的記憶體資料單元。然後，業務處理能力封裝成乙個個處理單元（prcessing unit）。訪問量增加，就新建處理單元；訪問量減少，就關閉處理單元。由於沒有**資料庫，所以擴充套件性的最大瓶頸消失了。由於每個處理單元的資料都在記憶體裡，最好要進行資料持久化。
這個模式主要分成兩部分：處理單元（processing unit）和虛擬中介軟體（virtualized middleware）。
處理單元：實現業務邏輯
虛擬中介軟體：負責通訊、保持sessions、資料複製、分布式處理、處理單元的部署。
閱讀任務 閱讀筆記 4
功能驅動的設計 1 構造總體模型 2 構造功能列表 3 制定開發計畫 4 功能設計階段 5 實現具體功能 軟體測試按目的分類 1 功能測試 2 非功能測試 軟體測試的各種方法 1 單元測試和 覆蓋率測試 2 構建驗證測試 3 驗收測試 4 探索式的測試 5 回歸測試 6 場景 整合 系統測試 7 夥...
YOLOv4閱讀筆記
中英對照翻譯參考 中首先總結了目標檢測的一般性結構 通常，傳統的目標檢測器是離線訓練的。因此，研究人員總是喜歡利用這一優勢，開發更好的訓練方法，使目標檢測器在不增加推理成本的情況下獲得更好的精度。我們將這些方法稱為 bag of freebies 這些方法僅改變訓練策略或僅增加訓練成本。資料擴充 資...
構建執法閱讀筆記4
第三章的主要內容和我們平時上課的內容關係不大，主要講的是畢業之後進入公司當一名軟體工程師，以及軟體工程師的發展與成長。這個話題我還是比較感興 趣的，畢竟在學校呆那麼久了，還是很期待進入社會進入公司，體驗職業帶來的新鮮感。一名合格的軟體工程師，規範化是基本素質，要想提高自己的技能，水平，要從平時的習慣...