博主從事了三年的saas產品開發，這三年的時間都在這一個saas產品上。該產品基本的架構是採取了微服務架構，後段採用java加Spring以及maven，前端使用的是jquery,UI5，數據庫則各個模塊各自使用自己需要的數據庫，主要是postgresql，以及mongodb。中間件則是使用的rabbitmq。部署在aws雲平臺上面。
後端
後端主要處理項目的核心業務邏輯。後端需要考慮下面這些：
- API versioning即暴露的接口的版本控制。爲什麼需要考慮這個問題，原因在於我們的接口一旦暴露給客戶使用之後，就必須保證接口的穩定性，不能因爲升級新功能導致老的接口就無法使用，這樣的產品是無法獲得用戶的好感的。因此，當有新的功能且這個功能需會改變接口的邏輯時，保留當前的接口，而提供一個新版本的接口就是一個很好的辦法。例如：老的接口爲：api/v1/customer. 新的接口爲：api/v2/customer。以此類推，但是需要主要的是，只有當必要的時候才應該去升級版本。
- Authorization訪問權限控制->即當調用api時需要提供的用戶名和密碼。可以考慮vault來進行管理。
- 不同service之間的依賴關係->contract保證
- log日誌格式，以及存儲位置，以及查看方法。比較常用的日誌查看工具有kibana
- 項目用到的構建工具，包管理->maven。對於java項目而言比較常用的還有gradle
- 代碼管理->github,使用branch管理代碼，要merge代碼到master branch需要人進行code review
- 代碼質量常見問題，例如code smell，security問題->sonar，vulas等工具
- 代碼質量保證->單元測試，集成測試，探索性測試
- 測試覆蓋率要求->對於java以及其對應的junit測試框架來說，junit提供了功能可以顯示代碼的測試覆蓋率。其結果用百分比顯示，表明代碼被測試的覆蓋程度。
- 代碼format格式風格統一
- 多個instance的時候，負載均衡,服務發現的問題，eruka在這方面可以提供支持。
- 部署問題。部署腳本比較成熟的方案是使用jenkins管理部署的流程。除此之外部署的其他方面也有很多問題。
- 不同service之間的通信問題。直接通信可以採取http call。解耦的通信可以使用message queue.
前端
- UI風格的整體性
- UI文本的翻譯支持,以及相關問題->對於全球化產品來說是必要的
- UI的權限訪問控制
- session會話管理
- UI和服務器通信的方式
- UI的緩存設計
- UI加載的速度
- UI的代碼質量保證，考慮使用checkmarx等靜態檢測工具
- UI代碼的測試問題，單元測試可以考慮Qunit，集成測試可以考慮night watch等工具
整體考慮的問題
- 項目的整體架構設計
- 開發規範定義. 例如對代碼命名，風格，測試的統一要求。開發規範最重要的是要保持一致性。
- 項目的開發模式，交付週期，發版方式
- 項目的部署平臺，部署流程，如何使用Jenkins 等工具。
- 如何控制項目的新功能上線->feature toggle.使用一個flag，若此flag打開，則新的feature生效，否則不生效。穩定之後則去除相關判斷代碼。
- scope問題。所謂哦scope指的是一個客戶的賬戶被賦予的權限。不同的權限所看到的內容，做的操作是不一樣的。
- 項目的運維，以及客戶上線後發現問題的處理
- 項目的功能劃分和管理，backlog的管理和實現流程
- 如何監控各個模塊的狀態,monitor的問題，日誌的存儲和查看。
- 訪問權限設置即權限生命週期管理
- 客戶登陸流程
- 項目功能介紹，api文檔撰寫以及更新
- bug修復規範以及流程，例如可以考慮對每一個發現的bug加一個對應的測試
- 項目的源代碼管理. 目前基本都採用Github.
- 前後端校驗邏輯的一致性問題-> 在產品開發的過程當中，我們對有的功能的校驗可能只會在前端作但是後端卻沒有做校驗。這樣可能帶來的一個就是我們正常通過UI進行的操作沒有問題，錯誤的請求和不對的數據結構會被擋在外面，但是同樣的錯誤的數據請求直接通過api去訪問，則會繞過UI的校驗，從而錯誤的數據會進入數據庫。到此還沒有結束，這個錯誤的數據如果不處理，在UI上顯示出來則會出現各種無法預料的後果。
- 數據遷移問題->有可能需要考慮
- 法律法規問題,遵守相關信息安全法規，例如GDPR
- 項目各種各樣的開發環境配置問題
除了上述之外，採用微服務架構還需要考慮很多微服務本身的問題。這方面可以參考博主其他的關於微服務的博客