業務現狀+領導要求
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. 所有基礎服務架構設計上需保持獨立性，元件化，模組化，盡量降低耦合，便於擴充套件，除錯，效能分析，優化。（以及未來組織架構上研發人員擴充，可以單獨深入負責某塊基礎服務的演變，無需了解整體）
總結說明
架構設計總為業務而服務，並非技術而技術；而業務現狀和公司的要求往往是讓架構設計最為糾結和取捨的，特別是考慮人員，資源，成本等各方面的限制，選擇乙個可行的方案。雲服務化是公司總體堅定的業務方向，基礎架構的沉澱和分布式的開發避無可避（而非傳統業務**拷貝到外網伺服器上就是雲服務了）。架構設計首先會以架構布局為優先，穩定性為次之，效能為更次之，同時必須兼顧到現實的運維情況；而後待業務發展，各方面相對穩定後，逐步推進優化，效能提公升，架構演變乃至推翻部分重建。
（以上文字分不同時間段總結而成，未校驗，不順之處請見諒！）
備忘錄系統 需求篇
設計資料庫 表結構 設計前後端互動介面 實現伺服器端和客戶端的邏輯 1.只支援單個使用者 2.實現針對文章的增刪查改 3.實現針對標籤的增刪查改 客戶端 網頁的形式 伺服器端 http協議 資料庫 mysql 展現備忘錄列表頁面 展現備忘錄詳情頁面 管理備忘錄頁面 例如 當使用者在客戶端 網頁 執行...
備忘錄模式
備忘錄模式 memento 在不破壞封裝性的前提下，捕獲乙個物件的內部狀態，並在該物件之外儲存這個狀態。這樣以後就可將該物件恢復到原先儲存的狀態。originator 發起人 負責建立乙個備忘錄memento，用以記錄當前時刻它的內部狀態，並可以使用備忘錄恢復內部狀態。originator可根據需要...
備忘錄模式
先從物件導向的三大特徵之一封裝說起。物件導向的封裝簡單點說就是把狀態 資料 和行為 操作這些資料的方法 放到一起，構成乙個單元，通常叫做類。乙個物件的行為是事先確定好的 靜態 一些指令碼，如果物件的狀態相同，物件看起來就是一樣的。所以當我們需要把乙個物件的某一時刻儲存起來，那麼只需要儲存它在那個時刻...