公司技术需求备忘录
業務現狀+領導要求
?
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）運維要求說明
目前公司的業務方向是大量的私有云推廣，意味著一些技術支持人員（工程部）在現場實施，每個現場的環境都不一樣?，F實情況是運維文檔很粗糙，單個基礎服務部署較艱難（如果使用第三方開源項目或者解決方案的話更加痛苦，有些開源項目專業人員部署都要好多天，更別提高可用和復雜的部署環境配置和調試），技術支持人員水平較低，運維人員人數有限等等，現實很殘酷！
@解決方案
1. 所有基礎服務都安裝配置完畢后，打包成一個私有云鏡像，以虛擬服務進程的方式提供整套的私有云基礎服務（理念: 云即服務，服務即云，一鍵部署，處處運行！）
2. 業務提供兩種部署方式：鏡像方式和安裝包方式。鏡像方式類似云服務的方式一鍵部署，安裝包方式須提供自動安裝腳本和手工部署文檔，還有版本升級包等方式，簡化安裝步驟。
3. 建立運維部署流程規范和知識庫體系，以應對各種復雜情況。
?
6）架構要求說明
公司業務開發人員技術能力偏下，同時業務的迭代進度要求高，沒有足夠的耐心了解沉淀技術知識。故而整體技術架構需清晰，簡單，獨立性明顯，容易理解和區分。出現問題需容易定位問題和排查，性能問題盡量不要讓業務開發人員關心?？蚣苁褂米銐蚝唵?#xff0c;技術文檔要足夠齊全，配套的架構方案實施需要有相關人員跟進，建議及監管，讓業務開發從技術細節中脫離出來，從而加快業務迭代速度。
@解決方案
1. 所有基礎架構需微服務化和sdk化，（同時避免sdk版本混亂，無論基礎服務功能有多復雜）僅提供一個統一的sdk解決方案，配套相應的技術咨詢人員和技術知識庫。
2. 基礎服務架構需概念清晰，簡單，能夠用幾個字就能表明用途和使用場景，容易在業務開發中推廣，落地使用。
3. 所有基礎服務架構設計上需保持獨立性，組件化，模塊化，盡量降低耦合，便于擴展，調試，性能分析，優化。（以及未來組織架構上研發人員擴充，可以單獨深入負責某塊基礎服務的演變，無需了解整體）
4. 統一公司所有基礎框架的使用和第三方框架的使用規范（接口即規范，Sdk即規范）,同時與公司基礎服務概念相同的公用第三方框架的使用，通過自研接口（適配器或者橋接模式）進行具體第三方框架實現的隔離和兼容，保證部分第三方框架的選擇和自研框架的演變，對于業務開發人員使用透明，無需更改代碼（甚至在線無縫切換）即可一鍵切換（通過配置中心）到不同實現。（如消息隊列和tcp通信服務等）
?
總結說明
架構設計總為業務而服務，并非技術而技術；而業務現狀和公司的要求往往是讓架構設計最為糾結和取舍的，特別是考慮人員，資源，成本等各方面的限制，選擇一個可行的方案。云服務化是公司總體堅定的業務方向，基礎架構的沉淀和分布式的開發避無可避（而非傳統業務代碼拷貝到外網服務器上就是云服務了）。架構設計首先會以架構布局為優先，穩定性為次之，性能為更次之，同時必須兼顧到現實的運維情況；而后待業務發展，各方面相對穩定后，逐步推進優化，性能提升，架構演變乃至推翻部分重建。
原文地址：http://www.cnblogs.com/chejiangyi/p/6252845.html
.NET社區新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注
總結
- 上一篇： 写给新手的WebAPI实践
- 下一篇： 写一个高性能的敏感词检测组件