SpringBoot和微服務架構
什么是SpringBoot
什么是Spring
Spirng是一個開源框架，2003年興起的一個輕量級的Java開發框架，作者：Rod Johnson。
Spring是為了解決企業級應用開發的復雜性而創建的簡化開發
Spring是如何簡化Java開發的
為了降低Java開發的復雜性，Spring采用了一下4種關鍵策略：
- 基於POJO的輕量級和最小入侵行編程；
- 通過IOC，依賴注入（DI）和面向接口實現松耦合；
- 基於切面（AOP）和慣例進行聲明式編程；
- 通過切面和模板減少樣式代碼
什么是SpringBoot
我管她是什么，好用就行了啊！！！但是無奈我的簡歷上寫了“精通SpringBoot”。。。那總得大體說得上SpringBoot是個啥東西吧！
Spring相信大家都用過，那一堆的配置，用起來就好比：你要吃飯，飯是熟的，但是你還要自己（配置）加油鹽醬醋，還得攪拌均勻，然后才能吃，，，
SpringBoot就不一樣了，直接給你端過來一碗香噴噴的牛肉拉面，哇，好香，，，，（好吧，寫這個博客的時候沒有吃飯，臆想一下，）你可以直接狼吞虎咽了有木有？啥？你想讓她幫你嚼碎然后喂你？！！！滾吧你。。。
一、關於Spring Boot
在開始了解Spring Boot之前，我們需要先了解一下Spring，因為Spring Boot的誕生和Spring是息息相關的，Spring Boot是Spring發展到一定程度的一個產物，但並不是Spring的替代品，Spring Boot是為了讓程序員更好的使用Spring。說到這里可能有些人會迷糊，那到底Spring和Spring Boot有着什么樣的聯系呢？
1.Spring發展史
在開始之前我們先了解一下Spring，Spring的前身是interface21，這個框架最初是為了解決EJB開發笨重臃腫的問題，為J2EE提供了另一種簡單又實用的解決方案，並在2004年3月發布了Spring 1.0正式版之后，就引起了Java界廣泛的關注和熱評，從此Spring在Java界勢如破竹迅速走紅，一路成為Java界一顆璀璨奪目的明星，至今無可替代，也一度成為J2EE開發中真正意義上的標准了，而他的創始人Rod Johnson也在之后聲名大噪，名利雙收，現在是一名優秀的天使投資人，走上了人生的巔峰。
2.Spring Boot誕生
那既然Spring已經這么優秀了，為什么還有了之后Spring Boot？
因為隨着Spring發展的越來越火，Spring也慢慢從一個小而精的框架變成了，一個覆蓋面廣大而全的框架，另一方面隨着新技術的發展，比如nodejs、golang、Ruby的興起，讓Spring逐漸看着笨重起來，大量繁瑣的XML配置和第三方整合配置，讓Spring使用者痛苦不已，這個時候急需一個解決方案，來解決這些問題。
就在這個節骨眼上Spring Boot應運而生，2013年Spring Boot開始研發，2014年4月Spring Boot 1.0正式發布，Spring Boot誕生之初就受到業界的廣泛關注，很多個人和企業陸續開始嘗試，隨着Spring Boot 2.0的發布，又一次把Spring Boot推向了公眾的視野，也有越來越多了的中大型企業把Spring Boot使用到正式的生產環境了。值得一提的是Spring官方也把Spring Boot作為首要的推廣項目，放到了官網的首位。
3.Spring Boot介紹
Spring Boot是由Pivotal團隊提供的全新框架，其設計目的是用來簡化Spring應用初始搭建以及開發過程。該框架使用了特定的方式來進行配置，從而使開發人員不再需要定義樣板化的配置。Spring Boot其實就是一個整合很多可插拔的組件（框架），內嵌了使用工具（比如內嵌了Tomcat、Jetty等），方便開發人員快速搭建和開發的一個框架。
上面的解釋是為了大家方便理解，加深記憶。。。下面看看官方的介紹：
Spring Boot makes it easy to create stand-alone, production-grade Spring based Applications that you can "just run".
We take an opinionated view of the Spring platform and third-party libraries so you can get started with minimum fuss. Most Spring Boot applications need very little Spring configuration.
我忍不住想翻譯一下：
Spring Boot使創建獨立的、基於生產級Spring的應用程序變得很容易，您可以“直接運行”這些應用程序。
我們對Spring平台和第三方庫有自己的見解，這樣您就可以輕松入門了。大多數Spring引導應用程序只需要很少的Spring配置。
大體意思就是說，她真的很好用，她可以讓你在服務的搭建時省去很多繁瑣的配置，用過之后的體驗：“簡直像是日了狗了”。。。
4.Spring Boot特點
- 搭建項目快，幾秒鍾就可以搭建完成；
- 讓測試變的簡單，內置了JUnit、Spring Boot Test等多種測試框架，方便測試；
- Spring Boot讓配置變的簡單，Spring Boot的核心理念：約定大約配置，約定了某種命名規范，可以不用配置，就可以完成功能開發，比如模型和表名一致就可以不用配置，直接進行CRUD（增刪改查）的操作，只有表名和模型不一致的時候，配置名稱即可；
- 內嵌容器，省去了配置Tomcat的繁瑣；
- 方便監控，使用Spring Boot Actuator組件提供了應用的系統監控，可以查看應用配置的詳細信息；
二、開發環境
Spring Boot 2.0.4
JDK 1.8
IDE：IntelliJ IDEA 2018.2
注意：Spring Boot 2.x 要求Java8及以上版本，不再支持Java6、Java7.
三、開發工具
IntelliJ IDEA Vs MyEclipse
開發工具的選擇是每一個人入門人員要經歷和選擇的，如果你是老手可以忽略本節。
曾幾何時Eclipse和MyEclipse統治了Java使用者，而如今，年復一年，毫不客氣的說，十年前我用MyEclipse 6.0到現在的MyEclipse 2017 我沒有感覺有任何的變化，還是一樣的皮膚，一樣的布局，一樣卡的起飛使用感受，即使按照Google的指引，優化了一堆配置之后，你也會發現收效甚微。
這讓我想起了曾經輝煌一時的諾基亞，到今天為止它依然不知道自己做錯了什么，但時過境遷當一個事物跟不上時代變化的節奏，它就會被新來更適合的事物所代替。不得不說我曾經也是MyEclipse的忠實熱愛者，並且對一個人來說一旦接受了某種事物，出於習慣的作用，通常改變也是很難的。
然而，到今天，我不得不承認IntelliJ IDEA從外觀到運行速度上要比MyEclipse好太多，尤其是對Spring Boot的支持上，更好天作之合，所以IntelliJ IDEA是最好的選擇。
四、Spring Boot版本號說明
官網上的SpringBoot版本如下圖所列：
那版本號后面的英文代表什么含義呢？
具體含義，如下文所示：
- SNAPSHOT：快照版，表示開發版本，隨時可能修改；
- M1（Mn）：M是milestone的縮寫，也就是里程碑版本；
- RC1（RCn）：RC是release candidates的縮寫，也就是發布預覽版；
- Release：正式版，也可能沒有任何后綴也表示正式版；
五,springBoot核心功能
☆ ** **獨立運行的spring項目：Spring Boot可以以jar包形式直接運行，如java-jar xxxjar優點是：節省服務器資源
☆ ** **內嵌servlet 容器：Spring Boot 可以選擇內嵌Tomcat，Jetty，這樣我們無須以war包形式部署項目。
☆ ** 提供starter 簡化Maven 配置：在Spring Boot 項目中為我們提供了很多的spring-boot-starter-xxx的項目（我們把這個依賴可以稱之為起步依賴**），我們導入指定的這些項目 的坐標，就會自動導入和該模塊相關的依賴包：
例如我們后期再使用Spring Boot 進行web開發我們就需要導入spring-boot-starter-web這個項目的依賴，導入這個依賴以后！那么Spring Boot就會自動導入web開發所需要 的其他的依賴包，如下圖所示：
☆ ** **自動配置 spring:Spring Boot 會根據在類路徑中的jar包，類，為jar包里的類自動配置Bean，這樣會極大減少我們要使用的配置。
當然Spring Boot只考慮了大部分開發場景，並不是所有的場景，如果在實際的開發中我們需要自動配置Bean，而Spring Boot不能滿足，則可以自定義自動配置。
☆ ** **准生產的應用監控：Spring Boot 提供基於http，sh，telnet對運行時的項目進行監控
☆ ** **無代碼生成和xml配置：Spring Boot大量使用spring4.x提供的注解新特性來實現無代碼生成和xml 配置。spring4.x提倡使用Java配置和注解配置組合，而Spring Boot不需要 任何xml配置即可實現spring的所有配置。
自動化配置是如何做到的？
spring boot給我們提供了很多的條件注解來完成
六、補充內容：
啥玩意！？你還不明白？還想更加“深入”的了解一下她？好吧那我就在給你貼點東西吧（有點亂，你隨便翻翻看看吧）：
北京時間 2018 年 3 月 1 日早上，如約發布的 Spring Boot 2.0 在同步至 Maven 倉庫時出現問題，導
致在 GitHub 上發布的 v2.0.0.RELEASE 被撤回。在問題修復后，官方重新發布了 Spring Boot 2.0，
並提供了 Maven 中央倉庫地址。至此 Spring Boot2.0 正式推出！
官方表示，這個版本經歷了 17 個月的開發，有 215 個不同的使用者提供了超過 6800 次的提交。非常感謝提
供貢獻的每一位用戶，並感謝所有對這些里程碑版本提供重要反饋的早期采用者。
該版本是自 4 年前發布 Spring Boot 1.0 以來的第一次重大修訂，也是首個提供對 Spring Framework 5.0
支持的 GA 穩定版本。
那去哪里找SpringBoot呢？
很好，這位同學問得好！：
怎么樣？這個地方熟悉吧，沒錯，這就是Spring家族，SB（SpringBoot，一下以及今后的博客簡稱SB）也是其中成員之一，你可以把她當做Spring的好朋友(●'◡'●)ﾉ(๑•₃•๑)或者閨蜜什么的，whatever吧。。。總之她讓我們在和Spring打交道的時候很方便了。
另外SpringBoot2.X之后真的是大換血了：
新版本值得關注的亮點：
1.基於 Java 8，支持 Java 9，這意味着不是不可以使用JDK7 或更舊的JDK版本運行SpringBoot2而是官方推薦使用JDK8+版本，你自己琢磨琢磨用還是用。。。.
2.支持 Quartz 調度程序
3.大大簡化了安全自動配置
4.支持嵌入式 Netty
5.Tomcat, Undertow 和 Jetty 均已支持 HTTP/2
6.全新的執行器架構，支持 Spring MVC, WebFlux 和 Jersey
7.使用 Spring WebFlux/WebFlux.fn 提供響應式 Web 編程支持
8.為各種組件的響應式編程提供了自動化配置，如：Reactive Spring Data、Reactive Spring Security 等
9.用於響應式 Spring Data Cassandra, MongoDB, Couchbase 和 Redis 的自動化配置和啟動器 POM
10.引入對 Kotlin 1.2.x 的支持，並提供了一個 runApplication 函數，讓你通過慣用的 Kotlin 來運行 Spring Boot 應用程序。更多信息請參閱參考文檔中對 Kotlin 的支持部分
11.啟動時的 ASCII 圖像 Spring Boot banner 現已支持 GIF
舉個栗子：
。。。
值得注意的一點是，在 Spring Boot 2.0 中，許多配置屬性已被重命名或被刪除，為了方便升級，Spring Boot 發布了一個新的 spring-boot-properties-migrator 模塊。只要將其作為依賴添加到項目中，它不僅會分析應用程序的環境並在啟動時打印診斷信息，而且還會在運行時階段為項目臨時將屬性遷移至新的配置方式。
在程序遷移至springboot2.0 期間，這個模塊是必備的
微服務架構
什么是微服務
微服務是一種架構風格，它要求我們在開發一個應用的時候，這個應用必須構建成一系列小服務的組合；可以通過http的方式進行互通。要說微服務架構，先得說說過去我們的單體應用架構
單體應用架構
所謂的單體應用架構（all in one）是指，我們將一個應用中的所有應用服務都封裝在一個應用中。無論是ERP、CRM或者其他什么系統，你都把數據庫訪、web訪問等等功能都放到一個war包內
優點：
- 易於開發和測試，便於部署；當需要擴展時，只需要將war復制多份，然后放到多個服務器上，再做個負載均衡就可以了
缺點：
- 修改一個非常小的地方，都需要停掉整個服務，重新打包、部署整個應用的war包。特別是對於一個大型應用，我們不可能把所有內容都放在一個應用里，我們如何維護、如何分工合作都是問題
微服務架構
all in one的架構方式，我們把所有的功能單元放在一個應用里。然后我們把整個應用部署到服務器上。如果負載能力不行，我們將整個應用進行水平復制，進行擴展，然后均衡負載
所謂的微服務架構，就是打破之前的all in one的架構方式，把每個功能元素獨立出來。把獨立出來的功能元素的動態組合，需要的功能元素才去拿來組合，需要多一些時可以整合多個功能元素。所以微服務架構是對功能元素進行復制，而沒有對整個應用進行復制。
優點：
- 節省了調用資源
- 每個功能元素的服務都是一個可替換的、可獨立升級的軟件代碼
- 易於開發和維護：一個服務只關注一個特定的業務功能，因此它業務清晰，代碼量少。開發和維護單個微服務至關簡單。而整個應用是若干個微服務構建而成的，因此整個應用在被維持在一個可控的狀態；
- 單個服務啟動快：單個服務代碼量少，因此啟動快；
- 局部修改易部署：單個應用只要有修改，就得從新部署整個應用，微服務解決了這個問題。通常來講，對某個微服務進行修改，只須要從新部署這個服務便可；
- 技術棧不受限：在微服務架構中，能夠結合業務和團隊的特色,合理選用技術棧。例若有些服務可使用關系型數據庫Mysql，有的服務可使用非關系型數據庫redis。甚至可根據需求，部分服務使用JAVA開發，部分微服務使用Node.js開發
- 按需收縮：可根據需求，實現細粒度的擴展。例如，系統中的某個微服務遇到了瓶頸，能夠結合微服務的特色，增長內存，升級CPU或增長節點。
缺點
- 運維要求高：更多的服務意味着更多的運維投入。在單體架構中，只須要保證一個應用的運行便可，在微服務中，須要保證幾十甚至幾百個服務器正常運行和協做，這給運維帶來了巨大的挑戰；
- 分戶式固有的復雜性：使用微服務架構的是分布式系統。對於一個分布式系統，系統容錯，網絡延遲都會帶來巨大挑戰。
- 接口調整成本高：微服務之間經過接口進行通訊