背景介紹
之前一直在做項目的工程化，導致很久沒有寫博客了，就在上週已經順利的發版了，涉及的項目有一個一般的分佈式項目，還有一個機器學習集成平臺，今天就總結一下工程化中的一些經驗。
爲什麼要做工程化
一般的開發流程是先做設計，設計在經過各方專家評審之後，開始編碼實現，現在開發的模式一般也是瀑布的開發模式，講究快速實現，快速迭代，所以開發的產品很容易會由於cpu/io/內存/網絡/線程池的大小/超時設計造成各種的瓶頸以及錯誤。
如果沒有好的工程化，運維階段就會有很多的問題。如果你的工程化做的不好，那麼就等着各種支持吧，配置怎麼配，軟件怎麼裝，很大的一部分時間都浪費在了支持上。如果工程化做的好，運維會按照文檔一步一步來，就順利的安裝好了，也就是用短的投入換來了不用一直的支持。
現場環境千變萬化，機器性能不一樣，依賴軟件的部署也不一樣，比如說有的地方顯卡是p4,有的地方怎是t4，還有的是p40, 衆所周知，這幾款顯卡的性能有很大的差別，t4的fp16性能好好，單p4就不行了。還有，有的現場安裝的是redis集羣，有的則是單機部署的。如果你的軟件不能很好的支持這種配置，後期部署的時候就會很麻煩，也會給現場造成一些不必要的浪費。
一些需要工程化的點
下面就分兩部分（一般軟件，機器學習軟件）介紹一下，工程化需要注意哪寫點
一般軟件
依賴軟件的各種部署與配置
對於軟件的各種存儲依賴和中間件依賴，一定要適配他們的各種部署方式，這裏列幾種常見的常用的軟件：
- redis
redis需要把配置文件給現場暴露出來，需要讓現場根據實際情況進行自定義的配置，如果現場已經有了現成的redis。則需要支持無縫的對接現場的redis 這裏需要注意的是redis的密碼，集羣部署方式，哨兵部署方式以及單機部署方式。同時還的做好數據落地持久化。 - minio
minio是一個對象存儲工具，部署方式的話有單節點，集羣。配置的話需要注意訪問的憑證，是否允許瀏覽器，以及存儲的位置等。 - mongo
mongo是一個介於關係和非關係的存儲軟件，也需要適配它的各種部署方式。 - mysql
- mq
- zookeeper
- es
- nginx
做代理的神器，配置需要面向運維，同時需要儘量的簡化配置，各種配置儘量做到傻瓜式、一鍵式。
總之各種軟件的依賴都需要考慮到各種可配置的配置項，以及各種可以寫死的配置，當然還需要適配各種部署方式。
線程池大小以及超時的配置
開發軟件的時候調試的樣本畢竟很少，可是現場會有各種各樣的情況，比如說處理超大文件，這會導致之前設置成超時時間太短，導致很多任務失敗，如果是大批量的小文件，這時可能之前設置的線程池大小就會偏小，導致資源的利用率不足。如果僅僅把這些線程池大小和超時時間給運維暴露出來，運維也可能不會配置。這時需要給軟件增加一個壓力感知層，讓軟件可以自適應的調整這些配置。對於運維，我們把一些端口號和ip交給他們就好了，其他的我們都自己內部調整就行。
軟件啓動腳本的自動化
軟件發佈出去之後，運維需要啓動軟件，這時候運維需要不斷的修改軟件的配置。不同的依賴修改不同的配置。這時候就需要寫一個自動化的啓動腳本，運維之需要把軟件複製過來，然後執行start就行。其他的就交給腳本吧。關於需要配置的東西，就寫一個config配置文件，用戶在啓動時候，把一些地址和端口給配進去，自動化的腳本會加載這個配置文件，並把這些變量放到對應的地方，這樣可以順利的啓動。
機器學習相關
顯存的控制
生產環境的時候一定要把顯存給控制好，如果設置的是顯存自增的方式，很有可能會把服務給掛了。
當然可以固定顯存的利用率，gpufraction = 0.2 可是在不同顯卡上，這個值設置需要注意，因爲有的顯卡是8g，有的可是16g,還有的是12g，同樣是0.2 實際佔用的可是不一樣，很有可能造成顯存浪費和啓動失敗。
多節點的啓動
一般機器學習也都是通過http來進行檢測的，每一個機器學習服務都是http服務，我們可以再有限的gpu上啓動儘可能多的節點，然後通過一個nginx掛起來，這樣就做成了一個簡單的集羣，可以有效的進行提速，當然需要通過時間的顯存以及顯卡利用率來判斷適合的數據。
tenosrrt 量化與加速
可以通過tensorrt來量化你的模型，並時間加速，如果是多個服務，可以吧圖像預處理給統一了，這樣也會減少很多時間，具體如何做量化，可以直接看官網的例子。
總結
總之，再做工程化的時候目標就是，資源佔用儘量少、運行速度快、準確率高、實施簡單。