一起来聊聊自己使用的企业级项目开发技术栈~
【赠书】《Spring Boot 开发实战》作者与你探讨最佳实践的开发-小虾2018参与的聚能聊话题-云栖社区 http://yq.aliyun.com/roundtable/325534/answer/608736#visit608736
1.Java 程序员到了必须学习 Spring Boot 的时候了吗？
说起 Spring Boot 我们不得不先了解一下 Spring 这个企业，不仅因为 Spring Boot 来源于 Spirng 大家族，而且 Spring Boot 的诞生和 Sping 框架的发展息息相关。
时间回到2002年，当时正是 Java EE 和 EJB 大行其道的时候，很多知名公司都是采用此技术方案进行项目开发。这时候有一个美国的小伙子认为 EJB 太过臃肿，并不是所有的项目都需要使用 EJB 这种大型框架，应该会有一种更好的方案来解决这个问题。
为了证明他的想法是正确的，于2002年10月甚至写了一本书《 Expert One-on-One J2EE 》，介绍了当时 Java 企业应用程序开发的情况，并指出了 Java EE 和 EJB 组件框架中存在的一些主要缺陷。在这本书中，他提出了一个基于普通 Java 类和依赖注入的更简单的解决方案。
随着使用 Spring 进行开发的个人和企业越来越多，Spring 也慢慢从一个单一简洁的小框架变成一个大而全的开源软件，Spring 的边界不断的进行扩充，到了后来 Spring 几乎可以做任何事情了，市面上主流的开源软件、中间件都有 Spring 对应组件支持，人们在享用 Spring 的这种便利之后，也遇到了一些问题。
Spring 每集成一个开源软件，就需要增加一些基础配置，慢慢的随着人们开发的项目越来越庞大，往往需要集成很多开源软件，因此后期使用 Spirng 开发大型项目需要引入很多配置文件，太多的配置非常难以理解，并容易配置出错，到了后来人们甚至称 Spring 为配置地狱。
Spring 似乎也意识到了这些问题，急需有这么一套软件可以解决这些问题，这个时候微服务的概念也慢慢兴起，快速开发微小独立的应用变得更为急迫，Spring 刚好处在这么一个交叉点上，于 2013 年初开始的 Spring Boot 项目的研发，2014年4月，Spring Boot 1.0.0 发布。
Spring Boot 诞生之初，就受到开源社区的持续关注，陆续有一些个人和企业尝试着使用了 Spring Boot，并迅速喜欢上了这款开源软件。直到2016年，在国内 Spring Boot 才被正真使用了起来，期间很多研究 Spring Boot 的开发者在网上写了大量关于 Spring Boot 的文章，同时有一些公司在企业内部进行了小规模的使用，并将使用经验分享了出来。从2016年到2018年，使用 Spring Boot 的企业和个人开发者越来越多，我们从 Spring Boot 关键字的百度指数就可以看出。
上图为2014年到2018年 Spring Boot 的百度指数，可以看出 Spring Boot 2.0 的推出引发了搜索高峰。
当然 Spring Boot 不是为了取代 Spring ,Spring Boot 基于 Spring 开发，是为了让人们更容易的使用 Spring。看到 Spring Boot 的市场反应，Spring 官方也非常重视 Spring Boot 的后续发展，已经将 Spring Boot 作为公司最顶级的项目来推广，放到了官网上第一的位置，因此后续 Spring Boot 的持续发展也被看好。
Spring Boot 特性
使用 Spring 项目引导页面可以在几秒构建一个项目
方便对外输出各种形式的服务，如 REST API、WebSocket、Web、Streaming、Tasks
非常简洁的安全策略集成
支持关系数据库和非关系数据库
支持运行期内嵌容器，如 Tomcat、Jetty
强大的开发包，支持热启动
自动管理依赖
自带应用监控
支持各种 IED，如 IntelliJ IDEA 、NetBeans
Spring Boot 这些特性会给我们研发带来非常大的优势！
2.我的Java语言用得很溜，还需要学习什么 Kotlin 吗？
下面这张图片来自 Code Complete 一书，展示了软件项目的各种活动所占的比例：
遵循 Steve McConnell 在 Code Complete 一书中提出的模式，我们可以将软件构建活动分解成三个子活动：详细设计、编码与调试、开发测试。
Kotlin 对于详细设计子活动没什么影响(这项活动通常独立于选用的特定的面向对象编程语言)，因此，在这一部分，Kotlin 和 Java 需要付出同样的努力。
据我所知，对于开发测试子活动，Kotlin 也没有提出什么革命性的东西。因此，开发测试需要付出的努力也一样。
就剩编码与调试子活动了。
在考虑了所有的情况之后，谷歌最终决定支持 Kotlin Anroid 开发。我认为，谷歌员工都是非常聪明的人，我相信他们在决定支持 Kotlin 之前已经进行了非常深入的分析。
Kotlin是JetBrains的一种新的编程语言。它首次出现在2011年，JetBrains推出了名为“科特林”的项目。 Kotlin是开源语言。
基本上像Java一样，C和C ++ - Kotlin也是“静态类型编程语言”。
Kotlin语言的好处
Kotlin编译为JVM字节码或JavaScript - 像Java一样，Bytecode也是Kotlin程序的编译格式。 字节码表示编程代码，一旦编译，就通过虚拟机而不是计算机的处理器运行。 通过使用这种方法，一旦编译并运行虚拟机，源代码就可以在任何平台上运行。 一旦kotlin程序被转换为字节码，它可以通过网络传输并由JVM（Java虚拟机）执行。
Kotlin程序可以使用所有现有的Java框架和库 - 是的，Kotlin程序可以使用所有现有的Java框架和库，甚至依赖于注释处理的高级框架也是如此。关于kotlin语言的主要重点是它可以轻松地与Maven的，摇篮和其他构建系统集成。
Kotlin可以轻松学习，平易近人。通过简单的阅读语言参考可以轻松学习。语言干净直观（易于使用和理解）。Kotlin看起来很像Scala，但更简单。
Kotlin是开放源码，没有收费。
将Java自动转换为Kotlin - JetBrains将IntelliJ集成了一个新功能，将Java转换为Kotlin，节省了大量的时间。而且它也节省了我们重新编写世代代码。
Kotlin的空安全性很好 - 现在摆脱NullPointerExceptions。这种类型的系统帮助我们避免空指针异常。在Kotlin系统中，系统只拒绝编译尝试分配或返回null的代码考虑以下示例 -
代码审查不是问题 - 科特林更注重可读性的语法，所以代码审查不是一个问题，它们仍然可以由那些不熟悉语言的团队成员完成。
Kotlin语言的特点
十亿美元的错误是正确的。 如上所述，Kotlin避免了空指针异常。 如果我们尝试分配或返回null到变量或函数，那么它将不会编译。
但是在某些特殊情况下，如果我们在程序中需要可空性，那么我们必须非常好地问Kotlin。 每个Nullable型都需要特别的护理和治疗。 我们不能像非可空类型那样对待它们，这是一件非常好的事情。
2017年谷歌I/O大会的最后，谷歌宣布将Kotlin语言作为安卓开发的一级编程语言。Kotlin由JetBrains公司开发，与Java 100%互通，并具备诸多Java尚不支持的新特性。谷歌称还将与JetBrains公司合作，为Kotlin设立一个非盈利基金会。
Kotlin的文件扩展名为.kt和.kts，使用Kotlin，你可以用更少的代码获得更多的功能。 而你写的代码越少，你犯的错误就越少。除此以外，他还有如下特点：
Kotlin编译为JVM字节码或JavaScript，方便在没有JVM的设备上运行。
Kotlin程序可以使用所有现有的Java框架和库，也就是说所有的现有程序不需要更改就可以直接被调用。
Kotlin可以轻松学习，平易近人。它的规则及其简单，语法规则少，易于学习。
Kotlin是开放源码，没有收费。虽然java也是开源语言，但是相比于其他的非开源的还是有一定优势的。
将Java自动转换为Kotlin，有强迫症的也可以这么搞，不用逼死强迫症的。
Kotlin的空安全性很好
代码审查不是问题。
精简语法和简明，看得懂，学得会，写得出。
空安全 Null Safety- 如上节所述，Kotlin避免了NullPointerException。
扩展函数Extension Functions- Kotlin允许我们扩展现有类的功能，而不继承它们。意味着Kotlin提供了扩展具有新功能的类的能力，而无需继承类。
智能Casts - 当谈到Casts时，Kotlin编译器真的很聪明。在许多情况下不需要在kotlin中使用显式转换操作符，但是在Kotlin中，对于不可变值有“is-checking”，在需要时自动插入
类型推断Type Inference- 在Kotlin中，有一件伟大的事情，你不必明确指定每个变量的类型（以清晰详细的方式）。但是，如果要明确定义数据类型，还可以这样做。
函数式编程Functional Programming- 重要的是Kotlin是一种功能性的编程语言。基本上，Kotlin由许多有用的方法组成，其中包括高阶函数，lambda表达式，运算符重载，惰性评估，运算符重载等等。
你可以摆脱util类让我们来讨论一下有关使用util类的丑陋事情。 你有没有一个项目没有他们？ 我们几乎不记得这一切。 Kotlin有一个聪明的解决方案 - 扩展功能 - 帮助你摆脱所有的util类一劳永逸。扩展函数几乎是一个通常的Kotlin函数。 但是当你声明它，你需要指定的实例将具有扩展功能的类。
3.Maven 已经这么强大了，Gradle 真的有那么好用吗？
Java世界中主要有三大构建工具：Ant、Maven和Gradle。经过几年的发展，Ant几乎销声匿迹、Maven也日薄西山，而Gradle的发展则如日中天。笔者有幸见证了Maven的没落和Gradle的兴起。Maven的主要功能主要分为5点，分别是依赖管理系统、多模块构建、一致的项目结构、一致的构建模型和插件机制。我们可以从这五个方面来分析一下Gradle比起Maven的先进之处。
依赖管理系统
Maven为Java世界引入了一个新的依赖管理系统。在Java世界中，可以用groupId、artifactId、version组成的Coordination（座标）唯一标识一个依赖。任何基于Maven构建的项目自身也必须定义这三项属性，生成的包可以是Jar包，也可以是war包或者ear包。一个典型的依赖引用如下所示：
junit
junit
4.12
test
org.springframework
spring-test
从上面可以看出当引用一个依赖时，version可以省略掉，这样在获取依赖时会选择最新的版本。而存储这些组件的仓库有远程仓库和本地仓库之分。远程仓库可以使用世界公用的central仓库，也可以使用Apache Nexus自建私有仓库；本地仓库则在本地计算机上。通过Maven安装目录下的settings.xml文件可以配置本地仓库的路径，以及采用的远程仓库的地址。
Gradle在设计的时候基本沿用了Maven的这套依赖管理体系。不过它在引用依赖时还是进行了一些改进。首先引用依赖方面变得非常简洁。
dependencies {
compile 'org.hibernate:hibernate-core:3.6.7.Final'
testCompile ‘junit:junit:4.+'
}
第二，Maven和Gradle对依赖项的scope有所不同。在Maven世界中，一个依赖项有6种scope，分别是complie(默认)、provided、runtime、test、system、import。而grade将其简化为了4种，compile、runtime、testCompile、testRuntime。那么如果想在gradle使用类似于provided的scope怎么办？别着急，由于gradle语言的强大表现力，我们可以轻松编写代码来实现类似于provided scope的概念（例如How to use provided scope for jar file in Gradle build?）。
第三点是Gradle支持动态的版本依赖。在版本号后面使用+号的方式可以实现动态的版本管理。
第四点是在解决依赖冲突方面Gradle的实现机制更加明确。使用Maven和Gradle进行依赖管理时都采用的是传递性依赖；而如果多个依赖项指向同一个依赖项的不同版本时就会引起依赖冲突。而Maven处理这种依赖关系往往是噩梦一般的存在。而Gradle在解决依赖冲突方面相对来说比较明确。
Maven将项目的构建周期限制的太死，你无法在构建周期中添加新的phase，只能将插件绑定到已有的phase上。而现在项目的构建过程变得越来越复杂，而且多样化，显然Maven对这种复杂度缺少足够的应变能力。比如你想在项目构建过程中进行一项压缩所有javascript的任务，那么就要绑定到Maven的现有的某个phase上，而显然貌似放在哪个phase都不太合适。而且这些phase都是串行的，整个执行下来是一条线，这也限制了Maven的构建效率。而Gradle在构建模型上则非常灵活。在Gradle世界里可以轻松创建一个task，并随时通过depends语法建立与已有task的依赖关系。甚至对于Java项目的构建来说，Gradle是通过名为java的插件来包含了一个对Java项目的构建周期，这等于Gradle本身直接与项目构建周期是解耦的。
插件机制
Maven和Gradle设计时都采用了插件机制。但显然Gradle更胜一筹。主要原因在于Maven是基于XML进行配置。所以其配置语法太受限于XML。即使实现很小的功能都需要设计一个插件，建立其与XML配置的关联。
Maven的设计核心Convention Over Configuration被Gradle更加发扬光大，而Gradle的配置即代码又超越了Maven。在Gradle中任何配置都可以作为代码被执行的，我们也可以随时使用已有的Ant脚本（Ant task是Gradle中的一等公民）、Java类库、Groovy类库来辅助完成构建任务的编写。
这种采用本身语言实现的DSL对本身语言项目进行构建管理的例子比比皆是。比如Rake和Ruby、Grunt和JavaScript、Sbt和Ruby…..而Gradle之所以使用Groovy语言实现，是因为Groovy比Java语言更具表现力，其语法特性更丰富，又兼具函数式的特点。这几年兴起的语言（比如Scala、Go、Swift）都属于强类型的语言，兼具面向对象和函数式的特点。
最后想说的Gradle的命令行比Maven的要强大的多。
4.在Docker容器中运行Spring Boot应用真的有那么方便吗？
Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的Linux机器上，也可以实现虚拟化，容器是完全使用沙箱机制，相互之间不会有任何接口。
接下来我们看看docker的故事。
环境管理复杂 - 从各种OS到各种中间件到各种app, 一款产品能够成功作为开发者需要关心的东西太多，且难于管理，这个问题几乎在所有现代IT相关行业都需要面对。
云计算时代的到来 - AWS的成功, 引导开发者将应用转移到 cloud 上, 解决了硬件管理的问题，然而中间件相关的问题依然存在 (所以openstack HEAT和 AWS cloudformation 都着力解决这个问题)。开发者思路变化提供了可能性。
虚拟化手段的变化 - cloud 时代采用标配硬件来降低成本，采用虚拟化手段来满足用户按需使用的需求以及保证可用性和隔离性。然而无论是KVM还是Xen在 docker 看来,都在浪费资源，因为用户需要的是高效运行环境而非OS, GuestOS既浪费资源又难于管理, 更加轻量级的LXC更加灵活和快速
LXC的移动性 - LXC在 linux 2.6 的 kernel 里就已经存在了，但是其设计之初并非为云计算考虑的，缺少标准化的描述手段和容器的可迁移性，决定其构建出的环境难于迁移和标准化管理(相对于KVM之类image和snapshot的概念)。docker 就在这个问题上做出实质性的革新。这是docker最独特的地方。
VM技术和容器技术对比
面对上述几个问题，docker设想是交付运行环境如同海运，OS如同一个货轮，每一个在OS基础上的软件都如同一个集装箱，用户可以通过标准化手段自由组装运行环境，同时集装箱的内容可以由用户自定义，也可以由专业人员制造。这样，交付一个软件，就是一系列标准化组件的集合的交付，如同乐高积木，用户只需要选择合适的积木组合，并且在最顶端署上自己的名字(最后个标准化组件是用户的app)。这也就是基于docker的PaaS产品的原型。
