公司技術需求備忘錄

業務現狀+領導要求

 

1) 部署環境要求: 公有云，私有云，原有院內系統。三套環境，兼容部署，一套代碼多環境支持。
2) 數據庫要求：sqlserver，orcale，mysql要兼容，一套代碼多庫運行。
3) 性能要求：可擴展行好，性能高，水平擴展能力強（加機器就能夠加強性能）。
4) 開發要求：簡單，容易，你們上手方便，文檔齊全，無需關心底層性能及實現。
5) 運維要求：部署快，最好一鍵運行，無部署環境問題。 

6) 架構要求：架構清晰，簡單；組件化，模塊化，微服務化；外部接口兼容，不一樣底層實現配置切換。

 

1）部署環境要求說明

目前的部署環境主要有公有云，私有云，原有院內系統以及一些常規的業務演示。 

公有云: 目前考慮的有阿里雲部署（線上），其餘雲部署（合做項目，線上），要求性能極好（應用可平行擴展部署，以便性能達到業務發展的承載能力）。

私有云: 目前考慮的是原有的院內系統升級爲私有云的形式部署整套雲服務業務（整套基礎服務將打包成虛擬機鏡像方式部署），要求雲服務性能能夠適應極低的硬件配置（院內前置機硬件水平不佳），也能正常運行。部署的狀況不少（業務的主要場景），故要求技術支持可以很是方便的部署（一鍵部署或者安裝包）及問題的排查。

原有院內系統：原有院內系統能夠考慮升級爲私有云的方式部署，部分新的技術方式（如ef，activemq等），也可使用，底層的一些實現可以相對兼容（如數據結構）。可是暫時也不作過多的考慮。

以上環境，業務開發人員須要作一些區分，以便運用相應的技術（原有院內系統沒有升級私有云，就沒法正常使用大部分基礎服務相關的功能）。一套代碼要兼容多套環境下的部署和正確配置，便於業務運行。

 

@解決方案

採用虛擬機鏡像的方式部署業務和基礎服務，以整套鏡像版本提供業務版本，簡化安裝，簡化運維，一鍵部署。

將來全部業務支持經過安裝包腳本的方式部署組件，部署服務，部署應用到基礎服務等，不然難以應用多種環境，不一樣兼容性等狀況。

基礎服務鏡像會以開源的形式驗證總體的兼容性和穩定性，經過開源反饋改進鏡像版本的穩定性。

 

2）數據庫要求說明

目前的數據庫環境主要是sqlserver，（但實際公司場景：有些院內特別要求及目前公司領導要求）必須支持orcale，mysql的數據庫平滑切換。即一套代碼兼容三種數據庫的操做方式，儘量少的方式或者經過修改配置的方式，一鍵切換不一樣數據庫。同時要求必須支持多庫操做（分業務庫和核心業務庫等），性能相對穩定。使用要簡單，開發容易上手，資料文檔要多！

 

@解決方案

採用entityframework框架，二次封裝插件。ef框架性能其實並不高（或者較差,將來的將來確定是一個數據庫的支持方向，但目前比較遙遠），可是可以兼容多種數據庫，經過切換不一樣驅動dll庫，能夠一套ef linq代碼，多種數據庫，多庫支持。國內外.net通用流行的開源框架，微軟開源支持，文檔衆多，極易上手使用。在業務開發的前期和中期，將會一直保持使用該框架；在業務發展的後期，將會考慮使用純sql編寫數據庫操做代碼，且業務數據庫考慮深度的拆庫和分表。

 

3）性能要求說明

1. 要求業務和底層基礎服務，具有架構上的擴展能力，經過加機器，升級硬件資源提高程序的性能。同時底層基礎服務必須支持高性能，極強的水平擴展能力（分佈式擴展能力），這樣基於基礎服務研發的業務，才能天生具有分佈式特性，天生具有性能擴展能力。

2. 實際公司的私有云環境的硬件性能其實不高，而開源的一些服務或者第三方解決方案每每對單臺服務器的性能要求其實會比想象中的偏高，更別提一些配套的相對複雜的高可用方案，不太適合實際業務的部署硬件環境。故在具有研發能力的狀況下，採用自研的方案提供更低配置兼容（1核2G的硬件服務器）的基礎服務能力（同時自研框架又要可以兼容第三方框架，這樣以便在不修改業務代碼狀況下就能夠在更高性能要求的公有云環境中大規模部署）。

 

4）開發要求 說明

目前公司內部的開發人員的技術水平很低，對基礎服務的一些相關概念不瞭解，相關的組件廣泛知識（如消息隊列，任務調度，redis）接觸不深（有些人自身學習慾望也不強）,短時間乃至長期內不容易改變現狀。

@解決方案

 1. 雖然能夠經過培訓等手段進行培養，可是基礎服務sdk層面更要提供一些很是簡潔精煉的接口調用，屏蔽大部分實現細節（對技術感興趣者能夠看開放權限的源碼）;

 2. 同時提供使用demo和不斷完善的技術文檔（知識庫體系），應對各類環境使用的問題自查，解答，知識沉澱和分享；

 3. 經過配置中心，鏈接池，線程池，監控平臺等手段，提供人工和自適應的性能調優，性能監控和分析，性能優化建議等（性能監控這塊須要不斷完善和監控體系建設）。

 4. 剝離性能和業務實現,沉澱與性能相關的技術細節爲基礎sdk或基礎服務平臺， 經過底層研發人員不斷監控和調優性能，提高整個業務平臺的性能和整體穩定性。

 

5）運維要求說明

目前公司的業務方向是大量的私有云推廣，意味着一些技術支持人員（工程部）在現場實施，每一個現場的環境都不同。現實狀況是運維文檔很粗糙，單個基礎服務部署較艱難（若是使用第三方開源項目或者解決方案的話更加痛苦，有些開源項目專業人員部署都要好多天，更別提升可用和複雜的部署環境配置和調試），技術支持人員水平較低，運維人員人數有限等等，現實很殘酷！

@解決方案

1. 全部基礎服務都安裝配置完畢後，打包成一個私有云鏡像，以虛擬服務進程的方式提供整套的私有云基礎服務（理念: 雲即服務，服務即雲，一鍵部署，到處運行！）

2. 業務提供兩種部署方式：鏡像方式和安裝包方式。鏡像方式相似雲服務的方式一鍵部署，安裝包方式須提供自動安裝腳本和手工部署文檔，還有版本升級包等方式，簡化安裝步驟。

3. 創建運維部署流程規範和知識庫體系，以應對各類複雜狀況。

 

6）架構要求說明

公司業務開發人員技術能力偏下，同時業務的迭代進度要求高，沒有足夠的耐心瞭解沉澱技術知識。故而總體技術架構需清晰，簡單，獨立性明顯，容易理解和區分。出現問題需容易定位問題和排查，性能問題儘可能不要讓業務開發人員關心。框架使用足夠簡單，技術文檔要足夠齊全，配套的架構方案實施須要有相關人員跟進，建議及監管，讓業務開發從技術細節中脫離出來，從而加快業務迭代速度。

@解決方案

1. 全部基礎架構需微服務化和sdk化，（同時避免sdk版本混亂，不管基礎服務功能有多複雜）僅提供一個統一的sdk解決方案，配套相應的技術諮詢人員和技術知識庫。

2. 基礎服務架構需概念清晰，簡單，可以用幾個字就能代表用途和使用場景，容易在業務開發中推廣，落地使用。

3. 全部基礎服務架構設計上需保持獨立性，組件化，模塊化，儘可能下降耦合，便於擴展，調試，性能分析，優化。（以及將來組織架構上研發人員擴充，能夠單獨深刻負責某塊基礎服務的演變，無需瞭解總體）

4. 統一公司全部基礎框架的使用和第三方框架的使用規範（接口即規範，Sdk即規範）,同時與公司基礎服務概念相同的公用第三方框架的使用，經過自研接口（適配器或者橋接模式）進行具體第三方框架實現的隔離和兼容，保證部分第三方框架的選擇和自研框架的演變，對於業務開發人員使用透明，無需更改代碼（甚至在線無縫切換）便可一鍵切換（經過配置中心）到不一樣實現。（如消息隊列和tcp通訊服務等）

 

總結說明

架構設計總爲業務而服務，並不是技術而技術；而業務現狀和公司的要求每每是讓架構設計最爲糾結和取捨的，特別是考慮人員，資源，成本等各方面的限制，選擇一個可行的方案。雲服務化是公司整體堅決的業務方向，基礎架構的沉澱和分佈式的開發避無可避（而非傳統業務代碼拷貝到外網服務器上就是雲服務了）。架構設計首先會以架構佈局爲優先，穩定性爲次之，性能爲更次之，同時必須兼顧到現實的運維狀況；然後待業務發展，各方面相對穩定後，逐步推動優化，性能提高，架構演變乃至推翻部分重建。

 

（以上文字分不一樣時間段總結而成，未校驗，不順之處請見諒！）