架構設計總為業務而服務，並非技術而技術；而業務現狀和公司的要求往往是讓架構設計最為糾結和取捨的，特別是考慮人員，資源，成本等各方面的限制，選擇一個可行的方案。雲服務化是公司總體堅定的業務方向，基礎架構的沉澱和分散式的開發避無可避（而非傳統業務代碼拷貝到外網伺服器上就是雲服務了）。架構設計首先會以架構... ...
業務現狀+領導要求 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通信服務等） 總結說明 架構設計總為業務而服務，並非技術而技術；而業務現狀和公司的要求往往是讓架構設計最為糾結和取捨的，特別是考慮人員，資源，成本等各方面的限制，選擇一個可行的方案。雲服務化是公司總體堅定的業務方向，基礎架構的沉澱和分散式的開發避無可避（而非傳統業務代碼拷貝到外網伺服器上就是雲服務了）。架構設計首先會以架構佈局為優先，穩定性為次之，性能為更次之，同時必須兼顧到現實的運維情況；而後待業務發展，各方面相對穩定後，逐步推進優化，性能提升，架構演變乃至推翻部分重建。 （以上文字分不同時間段總結而成，未校驗，不順之處請見諒！）
