697
搭建spring cloud微服務架構
在搭建環境之前，首先根據公司的業務定義微服務架構的代碼結構，因為考慮到不同行業，不同領域，不同業務，我這邊針對於所有行業做通用的架構模式。
項目整個架構使用maven來構建的，使用maven不僅僅是jar包的管控，重要的是要抓住maven的一個核心作用，那就是將整個項目按照模塊化的方式進行劃分，業務與業務之間解耦，然後將模塊化的業務再進行服務化或者組件化，這樣可以進行任意的項目或者平台的業務移植。
最後還要考慮到服務的細粒度拆分，比如：一個登錄的模塊，我們可以將所有跟登錄有關係的業務進行服務化（基礎信息驗證；用戶名、郵箱、手機驗證登錄；手機驗證碼獲取；驗證用戶是否綁定等等），最後針對於多服務進行服務的編排，這樣就做到了正在的微服務架構。
以上是我在做項目或架構的一些經驗分享給大家，閑話少說，下麵講一下整個架構的代碼結構：
commonservice： 公共服務項目，裏麵包含了所有的針對於spring cloud的相關服務
這邊隻列出了一部分，給大家講解一下：
commonservice-apigateway： 完全托管的服務，可輕鬆創建、發布、維護、監控和保護任意規模的api.
commonservice-cache：暴露出來的分布式緩存服務，不同係統可以直接集成調用。
commonservice-config：配置管理服務，可以把配置放到遠程服務器或者本地庫，集中化管理集群配置，當前支持本地存儲、Git以及Subversion等。
commonservice-eureka：雲端服務發現，一個基於 REST 的服務，用於定位服務，以實現雲端中間層服務發現和故障轉移（跟zookeeper注冊中心相似）
commonservice-mq：封裝了與Rocketmq,Rabbit、Kafka等發送接收消息的服務（主要是消息的生產者和消費者）。
commonservice-sso：封裝統一認證入口，之前使用cas集成，當前將統一認證修改為oauth2的統一認證方式（用戶登錄，token認證，設備剔除，和spring security進行權限低耦合）。
注意：spring cloud還涉及到很多的服務，這邊沒有統一列出，後麵會持續進行服務的集成，其中包括：Spring Cloud Sleuth（zipkin）， Turbine， Hystrix， bus企業總線，Zuul，ELK等，請大家時刻關注。
component：組件項目
component－base: 公共組件封裝，包括：過濾器、攔截器、監聽、注解，mybatis plus封裝（mybatis plus要比mybatis更牛一些，是mybatis的升級版本，裏麵進行了很對於基礎base的封裝，包括entity，dao，service的封裝和分頁的封裝等），數據源配置，common code封裝等。
component－mongodb: 針對於分布式文件存儲的數據庫的組件封裝。
component－notify: 針對於阿裏雲消息服務引擎封裝。（Notify是淘寶自主研發的一套消息服務引擎，是支撐雙11最為核心的係統之一，在淘寶和支付寶的核心交易場景中都有大量使用。消息係統的核心作用就是三點：解耦，異步和並行）
component－oss：針對阿裏雲文件存儲的組件封裝。
component－redis：針對分布式緩存的組件封裝（使用自定義注解方式，直接注入到方法層）。
component－rocketmq： 針對於阿裏雲消息中間件的組件封裝。
component－swagger： 針對RESTFUL接口的文檔在線自動生成+功能測試功能的組件封裝。
component－utils： 針對工具包組件封裝。
dealer、demo項目代表模塊項目。
其中每個模塊項目包含對外暴露的api接口，dao 數據訪問對象，service（服務端+客戶端）
當模塊項目啟動的時候，微服務就會注冊到eureka服務注冊中心，每一個微服務即是服務的生產者，又是服務的消費者。
上麵是我們公司做的部分企業架構，後麵還會持續完善，後麵的文章會介紹如何一步步搭建公司微服務架構，請各位時刻關注。
文章來源：搭建spring cloud微服務架構-項目結構介紹 - 開源中國社區
最後更新：2017-09-07 12:32:31