坑爹項目「spring-cloud-alibaba」，咱們也來一個

咱們一般說的SpringCloud，指的是Spring Cloud Netflix，在獨立的主機環境中也能使用部署，血統最爲正宗，後面的文中，指的都是它。雖然有些組件再也不維護了，但好在是能夠熱拔插的（除非你已經上了賊船）。

SpringCloud只是一堆規範，其中的組件是能夠替換的額。私覺得，若是你採用了SpringCloud技術棧，你就必需要搞一個本身的SpringCloud。受技術選擇傾向和功能的影響，你可能會選了N家公司的不一樣組件進行集成，你的大多數工做實際上是放在服務治理上。

原本，作些能夠替換的starter組件，是皆大歡喜的事情，可雲廠商們不這麼想。話說這aws，搞了個本身的SpringCloud，集成了本身的衆多的服務，相輔相成，賣的很好。因而Azure等，也搞了一套，只不過只能跑在本身的雲上。若是你用了，哪一天若是想換主機環境了，就會知道這些爸爸們是多麼的愛你。既然有這等功效，東方的一寡頭手癢了，也要追隨時代的潮流。

由於壟斷，是全部商業公司一輩子的追求啊。

這些坑爹項目，其價值甚至不如寫個SpringCloud教程。

搞就搞，不就是一個全家桶麼。

接下來咱們看一下，要實現一個SpringCloud，都須要作哪些步驟。

實現一個parent

顯得專業些，就弄個parent。相似的，若是你在搞基礎框架搭架子，也能夠這麼搞。

固然做用也是有的。使用parent來控制版本和依賴，是常常用的手段。parent常常與BOM相結合，BOM也是由Maven提供的功能，用來定義一套相互兼容的jar包版本集合，在pom文件裏，就是指在dependencyManagement標籤中定義的部分。

使用時只須要依賴該BOM文件，便可放心的使用須要的依賴jar包，且無需再指定版本號。BOM的維護方負責版本升級，並保證BOM中定義的jar包版本之間的兼容性。相似這種：

<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<version>${spring-boot.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
複製代碼

BOM是不少開源軟件的組織方式，尤爲是在組件較多，版本較亂的狀況下，可以爲使用者提供一個比較統一的環境。

對於咱們來講，就須要將經常使用的組件進行封裝，而後統一在BOM文件中進行維護。第一，功能要全；第二，版本要兼容。組裝一下，就是一個微服務框架了。

實現一些starter

使用過starter的人都知道，咱們只須要引進相應的jar包，而後在yml文件裏配置幾個參數，就可以獲取豐富的功能。這種神奇的事情都是由SpringBoot Starter完成的。

相似於java的SPI機制，SpringBoot將自動加載src/main/resources/META-INF/spring.factories中配置的信息，進行初始化操做。

接下來咱們實現這樣一個功能：被Owl註解修飾的方法，將自動打印一行日誌。

加入依賴

pom.xml

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-autoconfigure</artifactId>
    <optional>true</optional>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-aop</artifactId>
    <optional>true</optional>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-configuration-processor</artifactId>
    <optional>true</optional>
</dependency>
複製代碼

編寫註解

Owl.java

import java.lang.annotation.*;

@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Owl {
    String operationName() default "";
}
複製代碼

編寫自動配置

OwlAutoConfiguration.java

@Configuration
@Slf4j
public class OwlAutoConfiguration {
    static final String TAG_COMPONENT = "java";

    @Bean
    public OwlAspect owlTracingAspect() {
        return new OwlAspect();
    }

    @Aspect
    class OwlAspect {
        @Around("@annotation(com.sayhiai.arch.trace.annotation.OwlTrace)")
        public Object owlTraceProcess(ProceedingJoinPoint pjp) throws Throwable {
            final String cls = pjp.getTarget().getClass().getName();
            final String mName = pjp.getSignature().getName();
            log.debug("cls:" + cls + ",method:" + mName);

            return pjp.proceed();
        }
    }
}
複製代碼

載入配置

src/main/resources/META-INF/spring.factories

org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
com.sayhiai.core.owl.OwlAutoConfiguration
複製代碼

接下來，將你的代碼，打包成jar，在須要的工程中引入就能夠了。

組裝關鍵組件

其實仔細的看下來，SpringCloud的關鍵組件就那麼幾個。既然是組件，那就可以隨意替換，Netflix的版本作到了。

因此我以爲真要對社區有誠意的話，只須要獨立維護相應的組件就能夠。全搞成本身的，心不在此啊。

一個組件，加上一個starter，完美而優雅的組合，頂絕而歡暢的樂章，就像Consul同樣。

不囉嗦，咱們在《微服務不是所有，只是特定領域的子集》這篇裏講了大而全的圍繞着微服務的功能。在這裏，咱們簡單談一下SpringCloud的關鍵部位。

1、遠程調用RPC 2、註冊中心 3、熔斷、限流 4、網關

遠程調用RPC

SpringCloud默認的是Feign和Ribbon，主要是提供了遠程調用請求和解析，以及負載均衡的功能。客觀點來講，若是不用這兩個組件，就會愈來愈四不像，乾脆也別叫SpringCloud了，因此替換不得。

RPC會大量使用動態代理的功能，將你的字符串或者配置（由於網絡傳輸方便）搞成動態的接口。

你也能夠寫一個RPC進行集成，有不少教程教你手擼一個。

爸爸版的集成了個dubbo，dubbo就是個RPC。因此你一用這玩意，其餘的一些關鍵組件也得跟着全套的換，組件就不叫組件了!

註冊中心

服務註冊中心是微服務的另一個必備組件，用來協調服務提供者和調用者的相互發現，SpringCloud默認的註冊中心是Eureka。

爸爸版的用的是Nacos。Nacos的更新目前來看仍是比較活躍的，但真沒有必要集成在一個Cloud中。Nacos最好的方式仍是獨立發佈，而後維護一個starter。開發者能夠按照本身公司的環境進行有選擇性的集成或替換。集成一個組件的成本是比較低的，遠遠低於刪掉一堆自覺得是的功能。

SpringCloud還能夠選擇Zookeeper，或者Consul，甚至Etcd等，，進行註冊中心的搭建。目前，Eureka宣佈再也不維護後，Consul應該是首要選擇。

Consul自帶Dashboard和ACL，可以看到大多數你所關心的信息。爲了可以集成在咱們公司的體系中，你可能會開發一些後臺管理功能，進行更多的控制。這部分開發簡單，只須要作個界面，直接經過API讀取Consul的數據就能夠了。

集成本身的服務

假如你是一個服務提供商，不管是PAAS，仍是SAAS，均可以封裝一下，進行售賣了。

好比你提供了CDN，那就封裝一個xxx-cdn-spring-boot-starter；你想要把本身的搜索服務進行售賣，那就封裝一個xxx-search-spring-boot-starter組件。

starter的命名方式是**-spring-boot-starter，咱們也要這樣，顯的比較專業，像是一個牛逼公司出品的樣子。

要多弄幾個，顯的本身的產品豐富；也要控制數量，避免學習成本過高；要綁定本身的產品，讓用戶一旦使用，就沒法下車，造成所謂的粘性。

固然，想要加上-incubator後綴進入孵化器，仍是有點難度的。不過若是你的公司夠大，這些都不是事。

熔斷、限流

這部分已經被炒做成微服務體系的必備組件，但捫心自問，這個功能對於中小型的應用可能就是一個擺設。但咱們仍是要搞的，由於這是個賣點。

SpringCloud默認的組件是Hystrix，提供了多線程和信號量來控制的不一樣方式。惋惜的是Hystrix也宣佈再也不維護了，官方推薦的替換版本是resilience4j。

熔斷限流功能實際上是很是簡單的，同事花了一週時間就擼了個足夠用的組件。這部分的主要設計在於可以簡單的應用，最好是可以經過後臺配置實時生效。

爸爸版的是Sentinel，雖然也帶了個後臺，可是並無和註冊中心進行集成，搞了個不三不四。

我要用Sentinel，我本身集成就行了，用你個大頭鬼。

網關

網關，能夠作統一的降級、限流、認證受權、安全等，是微服務的又一個組件。SpringCloud默認的是Zuul，Zuul又有版本1和2之分。SpringCloud還能夠選擇Gateway進行網關控制。

你的公司用網關了麼？我保持疑問。見過不少到了C、D輪的公司，依然是簡單的Nginx簡單路由。

還有一種與語言無關的網關就是基於Nginx的Openresty，包括集成度更高的Kong。但這個商業化趨勢很明顯，故意將簡單的事情複雜化，穩定性待考究，頗有手段。

個人意思是說，網關不是必須的，也沒有好用的網關。這是個五十步笑百步的領域。

其餘

微服務中其餘重要的組件，包括日誌收集、調用鏈、持續集成等，這些SpringCloud們都沒有提供。這就對了。都是開發者，咱們會本身選擇。

重要的組件不集成，反而集成了一堆相似於OSS、ANS、SMS、MQ等非必須的功能，這就是偷奸耍滑了。

宣傳造勢

編寫example

什麼均可以沒有，但文檔和例子要有的。這和幣圈ICO的白皮書一個道理。你們看概念很牛逼，可真正用的就沒幾個。

要炒概念，抓龍頭。

例子要可以跑起來，固然用戶花點力氣也是能夠的。若是用戶跑不起來，那絕逼不是產品問題，而是使用者的能力問題。

營銷

王婆賣瓜自賣自詡的可信力不大，你只須要在發佈會或者分享會上露露面就以了。剩下的就交給舔狗們吧。只要行動上符合咱們的大戰略，那都是本身人。

必定要蹭蹭熱點，什麼火往什麼上靠。領導既然抽出人力讓你搞一個以公司名義的開源項目，那天然是項莊舞劍;意在沛公。不拿出點很是手段，不取得點驕傲的成績，那是說不過去的。

若是你有經費的話，那再好不過了。固然，碰上個能花數億元收購Flink的團隊只是運氣。如今，你只須要花幾十塊錢，就能買到一篇軟文，KPI高了拿獎金但是要好幾萬的，這點賬不會算那仍是別混了。

趕忙拿起手邊的電話訂購吧。

若是你的框架實在是沒有什麼特點的話，能夠拿知名的開源軟件，或者公司內的其餘優秀軟件站臺，互惠互利。作的不成熟沒關係，反正你用的又不是開源的版本。泥坑留給別人，芬芳留給本身。都是成年人的世界，不必那麼矜持。

#End

以名詞的角度來看：Spring是春的意思，Cloud是雲。

以動詞的角度來看：Spring是發春，Cloud是升上雲端。俯瞰大地，多麼美妙的景色，我都忍不住顫抖起來。

只不過，春回大地，全是狗屁。