原文在我的部落格：blog.zlb37.xyz/2018-04-20_…
目前對小型專案的討論非常少。對於大多數創業團隊來說，專案初始都不會太大，通常對開發速度和開發成本的要求低於開發質量，加上多數創業團隊的技術負責人快速解決具體問題的能力，但並沒有良好的架構設計能力。往往在專案龐大到一定程度後，整個專案的可維護性越來越差。我在上一家公司的時候，入職時面對的就是一個典型的不可維護專案，修改任何一處都要耗費數倍於重寫的時間，在得知技術負責人不想重寫整個專案後，我選擇了離職。
對於創業公司來說，存在著這麼幾個非常棘手的問題：
- **人員素質低。**創業團隊需要節約錢，於是通常喜歡低於市場價招程式設計師，甚至在校實習生。這些人員的素質良莠不齊，但總體上說，程式碼質量堪憂，規範性不懂，騷操作倒是很多。
- **人員流動大。**創業團隊往往員工成長較快，當薪資跟不上的時候，員工極易離職，甚至一些負責人都會離職。離職後留下的程式碼其他人往往都不願意去維護。
- **需求變化快。**不要說產品經理的習慣性改需求，就是老闆也會時不時的有什麼新的主意。為了速度，或者開發人員應付差事，
這些客觀問題是存在而且難以解決的，作為小型專案的技術負責人來說，需要利用這些有限的資源，儘量快速高質量的完成各種任務。
我負責的上一個專案完全使用RESTFul風格，每個API URL都對應著一個Resource，由Resource去呼叫Service（第三方服務）、Model（資料庫操作）。但隨著專案的增大，Resource的數量越來越多，截至目前，我們內部代號為“LSB”的專案後臺程式碼擁有153個Resource，雖然每個Resource的功能都比較簡單，但這麼多Resource導致專案越來越難以理解。由於部分需求的反覆修改，部分Resource也已經被改的面目全非。
不得不服RESTFul下的橫向擴充套件能力是如此之強，但擴充套件多了未免感覺像一個龐然大物。
所以決定按照微服務的方式拆分專案。
微服務架構強調的第一個重點就是業務系統需要徹底的元件化和服務化，原有的單個業務系統會拆分為多個可以獨立開發，設計，執行和運維的小應用。這些小應用之間通過服務完成互動和整合。每個小應用從前端，到後臺，資料庫訪問，資料庫都完全是獨立的一套。
那麼，根據這個標準，我們可以把一個公司的的系統分為以下幾個部分：
- 人事管理服務
- 客戶管理服務
- 內容釋出服務
這三個服務都有自己獨立的資料庫、後臺程式、UI，其中人事管理服務儲存了公司所有員工的資訊、許可權、憑證，為另外兩個服務提供RESTFul風格介面。其本身提供的UI可供公司人事部門管理員工，以及員工自己進行修改密碼等操作。
RESTFul有四個基本操作：POST、DELETE、PUT、GET，其設計這裡不再多說（大家可以看我的文章《REST - 如何抽象為資源（RESOURCE）》），簡單設計一下：
- 員工資源
- 增：新增員工
- 刪：刪除員工
- 改：修改員工資料
- 查：按條件查詢員工（開放）
- 員工許可權
- 增：為員工授權
- 刪：為員工解除授權
- 查：
- 查詢員工是否有某項許可權（開放）
- 查詢員工許可權列表
- 許可權資源
- 查：檢視許可權列表
這裡使用了類似RBAC的許可權模型，不懂的可以略過
這裡一個服務只有3個Resource，而且如果公司招的都是有全棧能力的程式設計師，這個就是一個人的活，非常好追責（額）。
經過按照微服務劃分的後，單個微服務開發難度非常低，即使員工能力有限，把這個服務安置按量的開發出來沒有什麼難度。其內部也非常好理解，即使人員有變動也很好維護。而且拆成這個種程度了，如果真的需求有變化，把這個微服務扔掉重新寫代價也不是很大。微服務架構比較好的解決了創業公司在開發小型專案的這個三個痛點。
不過，我感覺以後的業務程式設計師，不再像是一個技術崗位，而是像一個流水線工人，只有上面把需求設計整理好，聽話做出來就好。