技術框架篇--第4篇
用日誌記錄“開源軟體”的誕生
赤龍ERP開源地址：
點亮星標，感謝支援，加微信與開發者交流 kzca2000
準備工作
搭建基礎框架前，一定要準備好開發環境。先安裝軟體（以我本地環境為例），包括：
- IDE（Eclipse最新版）
- JDK1.8
- Tomcat8.5
- MySQL8.0
- Redis最新版
- SVN、Git
安裝流程不做詳細說明。說幾個需要注意的地方：
（1）Tomcat安裝好後需要對server.xml做一些配置和優化（埠、應用、域名、NIO、執行緒池、SSL等）
（2）對JVM做必要的記憶體配置優化
（3）MySQL安裝時注意編碼UTF-8
（4）Redis需要配置密碼和持久化（AOF）
框架的基本要求
搭建應用的底層框架，總是要或多或少的根據情景考慮一些問題，而不能是框架和技術的簡單堆砌。那麼搭建框架要滿足哪些要求呢？
（1）安全性：由於是資訊化管理系統，使用的使用者是企業內部的職員和高管，那麼對於安全性和許可權的考慮就要提升一個層次了。比如：誰能訪問哪些功能、誰能做哪些操作，誰能看到什麼資料、又使用什麼方式可以更便捷的實現各種安全性的考慮。
（2）降低資訊流的複雜性：簡單解釋一下，ERP系統是一個很特殊的系統，因為它是企業中複雜管理流程、業務流程、財務流程的實現。所以它有著嚴密的邏輯與流程，系統中幾乎沒有獨立的模組或功能，系統內部各部分互相依賴的複雜程度難以想象。如何降低這些依賴關係的複雜度，就是框架中迫不及待解決的問題。
（3）提高開發效率：資訊化系統開發時的一大特點就是程式碼複用程度高，無論是重複的增刪改查，還是表單處理，設定是各種報表，太多的重複工作會浪費太多的時間。開發人員應該把工作集中在邏輯和演算法上面，而不是這些簡單的複製貼上修改上。
（4）靈活的可配置可擴充套件：資訊化系統的另一個特色就是個性化需求非常高，即使對於一個簡單的流程，也可能出現多樣化的各種要求。這往往根據企業的管理情況而定。如何竭盡所能在減少客戶化開發的前提下，滿足更多的需求是我們要考慮的問題。
（5）降低學習成本和維護成本：由於這是一款開源軟體，我們要考慮的不能僅僅是高大上的技術使用，而是要能讓更多的開發者和使用者，可以快速部署，並進行個性化開發。無論在展示層、控制層、持久層，還是在各第三方元件的使用中都要儘量考慮到如何讓更多的人可以使用我們的軟體。
如何解決問題
針對以上的要求，我們如何設計系統，解決問題，並最終搭建滿足我們需求的底層框架呢？我們一起來嘗試摸索一下。
- 說到安全性，就離不開登陸、許可權、加密這些場景。
（1）登陸我使用了cas，它是一個SSO框架，採用票據驗證機制保證了，認證的安全。
（2）授權我採用了shiro框架與cas無縫整合，根據三類許可權的設定，保證了選單、按鈕、資料的精細控制
（3）加密包括對HTTP頭的加密（SSL），對關鍵業務資料的加密（AES、SHA1） - 降低資訊流的複雜性，最核心的是如何梳理，如何切分業務，模組之間如何互相呼叫。
（1）梳理和切分業務其實更多的是經驗問題，但有個通用的大原則，高內聚；也就是把關聯性極高的功能放在一起，而對外暴露必要的介面供呼叫即可。其中還要考慮到一些基礎資料的通用化設計。比如：組織資訊、職員資訊、主資料、資料字典等，單獨設計並對外提供有雙層快取的介面。（其中也要考慮到快取的更新策略）
（2）模組間我用Maven父子專案做了劃分，也為直接的介面呼叫和REST風格的API呼叫做了不同方式的設計 - 如何提高開發效率，應該是我們認真思考的話題。因為這真的很重要。如果處理得當甚至會節省30%-40%的研發時間。
（1）程式碼自動生成工具：我研發了一套可以自動生成Controller、Service、Dao、Model以及所有配置及註解的工具。當前這是基於我指定的程式碼規範。只需要修改兩到三個配置項，即可一鍵在專案下生成我們所需的程式碼。本來至少要編寫半小時的程式碼，現在只需要10秒鐘。
（2）可複用的工具包：十幾年積累的所有工具類可提供快速的靜態呼叫方式
（3）抽絲剝繭，獨立的功能設計：很多常用的第三方元件或技術的處理方式，抽象出來，加以複用。比如：執行緒、Redis、JMS、Socket、Json、Groovy、Mongo等。
（4）多功能的AOP處理：基本思路是通過AOP及自定義註解靈活加入各種輔助處理功能。比如：方法快取、自動set基礎欄位值、日誌處理、資料許可權控制等。
（5）必要的通用功能：通過Spring提供的技術，實現異常處理、型別轉換、資料驗證、API請求攔截等各種處理要求。 - 可配置可擴充套件其實說起來簡單做起來難。可能很多軟體都是這麼宣傳的，但真正做到的並不多。其實我認為主要做到如下幾點就可以了：
（1）欄位的可擴充套件，即可以通過配置的方式增加輔助欄位，並且能實現1對1結構，和1對多結構的兩種方式。
（2）流程的靈活處理。軟體往往設計上會固定某一主流程，只要設計上讓這一流程的組織不固定，而相對鬆散的實現即可。
（3）功能性模組的高度可配：比如許可權系統、報表系統、工作流、資料字典 - 最後一個是有關降低學習成本和維護成本的問題。我覺得這更多是因為要匹配開源的要求，開源的使用者多數是個人或小團體，這對於普及一款開源產品顯得尤為重要。怎麼做呢？
（1）用最普及的技術、最少的技術種類、實現更多的需求。
（2）提供最簡單的配置文件以實現程式部署。
對未來的考慮
為了考慮單體需求的激增，不得不應對高併發以及高可用的情景。所以現在技術選擇以及底層搭建時就一定要有所考量。當前框架一定要可以快速引入新技術並可以高效整合。我認為Springboot一定是Java語言當下是最優的選擇，也為SpringCloud的升級做了足夠準備。
當然其中還有很多要考慮的內容，比如：負載均衡、訊息佇列、資料匯流排、讀寫分離、非同步併發、降級限流等。在此不展開討論，如果有興趣可與開發者直接溝通。
後記
今天的日誌寫的比較長，但還沒有包括很多中介軟體的優化和配置說明，為了給開源軟體的使用者簡化他們的部署工作，我會在後面附加一個技術補充文章。
希望您讀完本文可以幫助筆者進入【碼雲】或【GitHub】點點星標。感謝大家的支援！