web專案分類：
1. 全新從頭開始研發的專案；
2. rebuild/refactor一個已經執行良好的專案；
3. 開發新的功能
微服務架構切入模式探討
一般來說，一個產品預計剛上線時並不會有太大的併發量和訪問量，那麼從頭開始研發的專案可以使用傳統的單機模式快速開發部署驗證，後續再做一個一個模組的重構部署為微服務的模式。
當然，在最初的開發時就應該考慮到將來的微服務化。
單體模式/微服務模式與系統複雜度開發效率的關係
需要微服務架構的訊號
1.應用變得越來越複雜和龐大，以至於新的開發人員需要太長的時間去理解，這會導致組織和專案的功能擴張會成為一個重大的問題，每增加一個功能變得風險越來越大
2.應用的不同部分具有獨立的完全不同的更新頻率
3.系統的不同部分可能會強制開發人員使用一種語言和框架去開發，比如web主專案使用PHP開發，而人工智慧model更多的是用python訓練和服務，那麼就需要考慮使用ptyhon開發人工智慧模型預測服務
web service:
a way to expose the functionality/data of one application to other applications using http
micro service
a service oriented architecture(SOA) of developing software applications such that the application is made up multiple loosely-counpled and independent modules
API
the language used by different modules and applications to communicate with each other.
微服務系統設計原則
High Cohesion
single focus並且do well, SOLID(single responsibility),only change for one reason.類似於OOP中的類，類將相關的資料集方法打包成一個類
Autonomous
鬆耦合，面向介面的程式設計。
微服務應該是無狀態的，無需記憶以前的狀態。
backward compatible也是很重要的，否則一個微服務的變更，必將導致其他服務的相容問題。
定義清晰的input, output保證多個微服務可以同步進行開發
Business Domain Centric
每一個service可能對應著一個business function，和組織的架構相對映。
Resilience
如果一個微服務down,相應依賴他的微服務應該能夠downgrade，並且微服務可以通過註冊服務到管理單元，以後就route服務到其他的微服務單元。
Observable
需要有central monitoring, central logging監控系統的健康
Automation
需要持續整合CI，testing，deployment
Hosting platforms
virtualization
containers
self hosting
registry and discover
新專案開發面向微服務的探索
由於新專案中系統的需求和邊界可能並不是非常清晰，同時如果團隊本身對微服務並不是非常擅長，則建議還是先以單體模式快速開發產品，隨著產品的試用對不同domain之間的邊界越來越清晰，那麼就可以開始重構系統。首先將具有公共服務性的模組做成一個微服務，逐漸演進。。。
微服務架構技術棧總圖
API閘道器在這個體系結構中起到非常重要的作用，他是對外暴露的唯一介面，他接收使用者的訪問請求，並且代理路由所有的微服務請求並且變換轉發結果給使用者。比如kong gateway是非常強大的api閘道器產品
微服務的持續整合與部署
docker jenkins,gitlab,k8s
https://www.cnblogs.com/java-zhao/p/6065268.html
總體流程:
- 在開發機開發程式碼後提交到gitlab
- 之後通過webhook外掛觸發jenkins進行構建，jenkins將程式碼打成docker映象，push到docker-registry
- 之後將在k8s-master上執行rc、service的建立，進而建立Pod，從私服拉取映象，根據該映象啟動容器
https://blog.catscarlet.com/201612082623.html
https://zhuanlan.zhihu.com/p/21563604
Docker
Docker解決了微服務架構下，服務的粒度細服務數量多所導致的開發環境搭建，部署以及運維成本高的問題，也可以大大降低隨著微服務數量增多所導致的節點數量增多的成本。
SOA vs 微服務
SOA:將服務分解成多個子系統來實現，粒度比較大，基於企業服務匯流排，集中式的服務架構，屬於單塊架構系統，相互依賴，部署複雜，整合方式依賴於SOAP/ESB/WS等重量級協議；
微服務則自底向上開展實施，一個系統被才分成多個粒度精細的服務，整合方式為HTTP/REST/JSON輕量級協議，無集中式匯流排，服務能夠獨立部署，特別是基於docker技術。
總的來說，微服務是傳統SOA的一個子集；
微服務vs共享庫
微服務通常與語言無關，平臺無關。
微服務提倡圍繞業務組織團隊，微服務的模式往往要求團隊成員更有多樣性的能力，不像傳統的安裝技術能力範疇劃分：前端，後端，使用者體驗UI等團隊。
微服務架構屬於產品導向，比傳統的專案導向使得團隊更有主人翁意識，負責整個服務的整個生命週期。從服務的分析，開發，測試，部署到運維每個環節都要有服務的團隊成員來負責。
實際上我可以這樣理解：每個服務都是一個scrum團隊，有前端ui，有前後端開發，有測試，有dba人員，是一個戰鬥的團隊。多個scrum team組成整個產品的master專案。
技術選型
對於傳統的單塊架構系統，最初的技術選型將嚴重製約限制將來的技術演進能力，如果想嘗試新的程式語言或者框架，是非常困難的。而微服務架構則可以依據評估服務的重要程度以及團隊的能力選擇一個服務作為試點切換語言或者框架，快速完成，成功後可以應用到所有的服務模組，甚至就使用不同的語言和框架。
jenkins是一個java編寫的開源CI/CD系統
https://jenkins.io/
單點登入SSO
https://www.cnblogs.com/liuche/p/7955462.html
https://blog.csdn.net/why_2012_gogo/article/details/74137631