从架构师视角看是否该用Kotlin作服务端开发？

前言

自从Oracle收购Sun以后，对Java收费或增强控制的尝试从未间断，谷歌与Oracle围绕Java API的官司也跌宕起伏。虽然Oracle只是针对Oracle JDK8的升级收费，并释放了OpenJDK一直开源这份善意，可是若是没有各个大非Oracle的JVM、JDK和众多其它基于JVM的语言，Oracle这份善意能维持到何时可很差说。

大厂要从JVM和JDK的层面早作打算，而广大中小企业，就只能先从Java语言的层面，先找到Oracle之外的备胎。自从被谷歌钦定为Android开发首选语言以后，采用Apache2.0 License的Kotlin逐渐进入大众的视野。从领域语言到通用语言，基于JVM的语言选择众多，Kotlin能脱颖而出被谷歌相中，除了License的友好外，天然有其独到之处（我的以为基于Python语法的Jython在当时也算是一个强强联合的选择，固然如今来看Kotlin的优点明显）。咱们先从摘自网上的一个段子来感觉下Kotlin的特色：

• Scala：想解决Java表达能力不足的问题
• Groovy：想解决Java语法过于冗长的问题
• Clojure：想解决Java没有函数式编程的问题
• Kotlin：想解决Java

固然，团队开发比我的开发要考虑的问题更多，本文从研发团队的视角，来审视在服务端开发项目中是否应该使用Kotlin。而关于Kotlin语言细节，详情请你们参移动Kotlin官方文档或搜索引擎去了解更多，本文就不详细展开。

选择Kotlin的理由

1. 与Java近乎完美的兼容

做为团队技术预研，我已小试牛刀使用Kotlin作了一小一中真实上线项目，包括CI\CD、Spring全家桶、MyBatis、RDMS、NoSQL、消息队列、微服务、RESTful接口、鉴权、计费等全面实践，除项目代码以外的也用Kotlin实现了爬虫、运维、测试工具等。这其中除了BenchMark性能测试因OpenJDK:jmh直接操做字节码而须要编译比java略复杂外，全部事件都能作到人(Java)无我(Kotlin)有，人(Java)有我(Kotlin)强，只身十天左右就能高质量从零完成一套AI SaaS服务的开发、测试。

我自身的实践能够说明，Kotlin使用Java的开源组件、类库、工具栈上与Java代码自己几乎(仅发现jmh有些许差异外)没有差异，这是其它基于JVM的语言没法比拟有优点。

2. 更易写出可靠的代码

2.1 强制非空校验

// 全部变量默认不能为空
var a: String = "abc"
a = null //编译错误
// 若是想要容许变量为空，变量声明中的类型以"?"结尾
var b: String? = null
// 非空类型的变量，能够直接调用对象方法
println(a.length)
 // 可空类型的变量，能够用"?."替换"."来进行彻底调用
println(b?.length) //若是b为null，则b?.length返回null，而不会抛出NPE
// "?."链式调用更显安全调用的威力
bob?.department?.head?.name //只要有一环为null，则整个表达式返回null
// 空类型不能直接赋值给非空类型
a = b //编译错误
// 可使用非空断言"!!"来强制将b转换为其对应的非空类型
a = b!! //若是b为null，则抛出NPE，不然赋值成功
// 更安全的作法是使用"?:"赋值
a = b?:"Default"
// "?:"还能够接”throw“、"return"、"break"语句来提早结束函数或语句块
a = b?: throw MyException("自定义异常")

能够看到，Kotlin经过强制非空校验机制，规避了Java最易犯的NPE问题，而且在不额外增长判空代码的状况下，很容易写出空安全的代码，固然也经过非空断言保留了抛出NPE的途径，具体请参考Kotlin官方文档-空安全

2.2 只读变量

// 经过val能够方便声明只读变量，防止变量的误修改，相似于java的final
val a = "Hello"
//...
a = "world" //编译错误
// var用于声明可读写变量
var b = 1 //若是下方没有代码对b进行修改，则编译告警

声明只读变量的语法更简洁，配合var未修改编译告警，强制开发人员明白无误地声明变量

3. 简洁高效，代码量可减小逾50%

3.1 默认参数与数据类

// 默认参数，大多数状况能够代替函数重载
fun a(name: String, age: Int = 0) {
  //...
}

// data关键字会自动为类型增长hashCode(),equals(),copy(),toString()方法
// val关键字会自动生成只读成员变量及get方法
// var关键字会自动生成成员变量及get和set方法
data class Person(val id: Int, var name: String, var age: Int = 0)
//以上就是Person实体的完整声明，它等价于十行以上的java代码

默认参数、数据类、主构造函数的组合使用，让咱们节省了90%以上的实体声明代码，且表达能力更清晰，可维护性更强

3.2 类型推断

when(val u = request.session.getAttribute("user")){
  is String -> println(u.toUpperCase())
  is Map<*, *> -> println(u["name"])
  !is List<*> -> println(u)
}

在类型判断代码以后，变量会自动转换为须要的类型，省去变量声明和类型转换代码。

除此以外Kotlin拥有着丰富的集合操做，以及类扩展、更简洁的lambda、字符串模板、操做符重载、解构等等几乎包含了如今语言的全部优良特征，让业务代码节省50%以上，且表义能力更强。

4. Spring的加成

Spring-Boot已经将kotlin提高为仅次于Java的推荐语言，足以见得Spring对Kotlin重视

4.1 构造函数注入

Spring构造函数注入配置kotlin的主构造函数语法，Spring+Kotlin天生就很搭

@Service
class SMSService(
  @Value("\${sms.appId}") private val appId: String,
  @Value("\${sms.appSecret}") private val appSecurity: String,
  private val webClient: WebClient
) {
  //...
}

4.2 针对Kotlin的扩展
Spring中还有部分专门针对Kotlin的扩展如： SpringApplicationExtension:

@SpringBootApplication
class SpringBootApplicationStarter

fun main(args: Array<String>) {
  //拉起Spring-Boot应用
  runApplication<SpringBootApplicationStarter>(*args)
}

4.3 针对Kotlin的示例代码

Spring文档专门为Kotlin编写了示例代码，这但是Spring支持的老牌语言Groovy多年都没享受到的待遇：

Kotlin天生对Spring的友好，以及Spring对Kotlin的重视和加成，能够预见Kotlin将来在服务器开发领域的地位会愈来愈高。

选择Kotlin须要考虑的问题

1. IDE&工具链

Kotlin首选开发工具非同属jetbrain公司的IDEA莫属
Eclipse+Kotlin Plugin也是不错的选择
两者Kotlin的开发体验都不输于Java的开发体验
不过Eclipse的Kotlin插件存在两个问题：
1) Debug不能自动识别Kotlin的main方法，须要手工填入Class名；
2) Debug不支持Kotlin编译的allopen选项，全部Bean和Configuration类型须显示声明为open

@SpringBootApplication
open class SpringBootApplicationStarter

@Configuration
open class BeanConfig

@Service
open class TestService

@RestController
open class TestController

在IDE以外，Kotlin能完美地运行于Maven和Gradle之上，CI/CD工具Jenkins天然不在话下，JUnit、Swagger等Java原有工具链运行起来都没有差异，在字节码和jar包以外的各类工具可否运行，理论上并不取决于项目代码是Kotlin仍是Java；可能最大的问题在于，原有的代码检查工具不能再继承使用。

2. 编码规范

Kotlin放开了不少限制如：

• 能够声明全局变量和全局方法
• 一个文件能够有多个类
• 能够经过扩展来为已有类增长新方法

这带来了诸多便利，如同一领域的实体能够声明在一个文件中：

//WebResponses.kt
open class WebResponse(var errorCode: Int = 0, var errorMsg: String? = null)

open class DataResponse<T>(var data: T?) : WebResponse()

open class MapResponse<K, V>(map: Map<K, V>) : DataResponse<Map<K, V>>(map) {
    constructor(vararg pairs: Pair<K, V>) : this(mutableMapOf(*pairs))
}

能够很方便地扩展已有类库

// StringExtensions.kt
val REGEX_Digits = Regex("\\\d+")
fun String.isDigits(): Boolean {
    return this.matches(REGEX_Digits)
}
// ACLInterceptor
val appId = request.getParameter("appId")
if (!appId.isNullOrBlank() && appId.isDigits()) {
//...
}

可是若是不加限制，很难保证开发人员不为所欲为。因此应该针对Kotlin项目制定一些编码规范(能够与Android项目共用)，如：

• 只有数据实体能够定义在同一个文件中
• 类型扩展应以”Extensions“后缀结尾，如"StringExtensions"
• 业务逻辑不该出如今全局方法中，应按照一类一文件的方式组织
• 业务逻辑的扩展，不该使用Kotlin类型扩展机制，而应使用接口、抽象类、子类

3. 人员技能

对Java开发人员来讲，学习Kotlin并非什么困难的事情，以我我的的经验，直接以一个小项目开始的状况下，一周以内编码效率就会明显超过Java。

固然，语言工具不是项目成败的决定性因素，使用工具的人才是，不妨先让项目组中的核心成员去了解下Kotlin，再作决定。

快速上手建议从Koans开始，想要更深刻地掌握，仍是要阅读Kotlin官方文档

4. 依赖大小

在Spring项目中使用Kotlin会使依赖增长4.18MB左右

这在Spring-Boot兴起以前，对我来讲确实是个问题，6年前一个war包也就3~5MB大小，还要为Tomcat能部署多个服务而不会代码空间溢出，把war包进一步瘦身——把公共jar包都放入Tomcat/lib之下。

而如今Spring-Boot项目动则30MB起步的大小，让我已经再也不考虑服务器资源的问题，而更享受各类组件和工具带来的开发效率提高。

固然这个问题，因项目实际状况而异，须要交给做为架构师的你本身去决策。

5. BenchMark

具体细节本不是此文的讨论目标，且对Kotlin作BenchMark性能测试不是那么困难，可是Kotlin的BenchMark资料也很少，这里我附送一个简明教程：

• 步骤1：使用maven生成Kotlin benchmark工程

mvn archetype:generate \
          -DinteractiveMode=false \
          -DarchetypeGroupId=org.openjdk.jmh \
          -DarchetypeArtifactId=jmh-kotlin-benchmark-archetype \
          -DgroupId=org.sample \
          -DartifactId=test \
          -Dversion=1.0

• 步骤2：编写测试代码

@BenchmarkMode(Mode.Throughput)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
open class MyBenchmark {
	@Benchmark
	fun testMethod1() {
		//...
	}

	@Benchmark
	fun testMethod2() {
		//...
	}
}

• 步骤3：编译&运行

mvn clean package
java -jar target/benchmarks.jar

更多性能测试详情，可参考

• OpenJDK:jmh官网
• kotlin-benchmarks项目

哪些项目类型适合使用Kotlin

1. 现有Java项目，不推荐；
2. 小型或验证型项目，强烈推荐；
3. 微服务项目，推荐先局部试点，逐步完善编码规范和人员技能；
4. 大型单体项目，有较强较稳定的核心团队时推荐，人员主靠招聘时不推荐；
5. 公共组件，不推荐，除专门用于Kotlin的组件外。

结语

无论怎么说，语言工具不是项目成败的决定性因素，使用工具的人才是，不妨先让项目组中的核心成员去了解下Kotlin，再作决定。