朱晔和你聊Spring系列S1E1：聊聊Spring家族的几大件

朱晔和你聊Spring系列S1E1：聊聊Spring家族的几大件

 

【下载本文PDF进行阅读】

 

Spring家族很庞大，从最先先出现的服务于企业级程序开发的Core、安全方面的Security、到后来的做为各类数据源桥梁的Data、最近几年很火的Boot，以及最新推出的正在蓬勃发展的Cloud（在本文以后都简单称为Boot、Cloud省略Spring节省一点个人打字时间😊）。

上面这个脑图给出了Spring家族主要的一些成员，右侧非Cloud部分列的是功能，左侧Cloud部分虽然组件繁杂，可是结构清晰（确实新版本清晰多了，命名也统一，你能够放大图片看一下这些是否熟悉），因此更进一步列出了组件要的一些模块依赖和开启功能的主注解。

 

我说Spring的发展

 

Spring框架几乎涉及到了Java企业级服务开发的全部方面，也几乎针对全部开发经常使用的模式、中间件、数据库进行了整合适配。

以前在聊互联网架构模式的时候我谈到过，不少时候咱们写一个业务把逻辑写死写出来是比较容易的，可是把这个逻辑提取成模式进而打包成一个框架来给你们使用，这是比较难的。由于咱们只有经历过足够多的场景后才能提取出普适的功能框架，大部分人才能用上，并且咱们须要针对核心功能开放出可配置的部分，知足小部分人进一步定制和扩展功能的须要。

Spring框架经历了几个阶段：

• 第一个阶段推出的Core、Security、Data是把单体应用开发服务好。不只仅提供了便捷的数据库访问、Web MVC等必要功能，并且经过AOP、IOC两大利器让咱们的程序内在可以作到低耦合可扩展。
• 第二个阶段推出的Boot的意义不只仅是加速了开发效率并且能让咱们的程序从可用变为好用，应用程序核心业务逻辑可能只有70%的工做量，要让程序在线上跑的愉快还有30%的监控日志打点等工做量须要去作。
• 第三个阶段推出的Cloud的意义在于推进了微服务架构的落地。让不具有开发微服务基础套件的小型互联网公司也能享受到免费的开箱即用的微服务解决方案。其实不少人不是看了微服务的架构思想去寻找解决方案，而是了解到了Spring Cloud才去了解微服务思想从而落地的。
• 目前属于第四个阶段，大力发展Cloud Dataflow+容器。Dataflow的思想是无论是作实时消息处理的服务仍是临时运行的任务，均可以认为是服务的组件，若是能够有一套DSL来定义这些组件之间的交互方式，而后在容器中进行自由组合、部署、伸缩，那么架构会很是灵活。下图是Dataflow管理界面的一个示意图。

 

Spring的发展能够看到互联网架构的发展，Spring给咱们带来至关多的技术启发，从软件设计模式的启发慢慢到了架构的启发，甚至我以为Spring是为Java开发打造了架构风格的模板，接下去Spring继续发展2到3年有望成为架构标准，我在想这个时候应用架构师何去何从？

 

我说Spring Core

 

Spring Core提供的IOC、AOP功能已经变为半个Java命根子了。其实不少开发平台并非那么强调IOC和AOP，甚至有的平台彻底没有相关支持。虽然我一直以为IOC和AOP是很是好的思想，可让咱们的软件内部作到组件之间的低耦合，容易替换，容易扩展，可是个人观点是，做为一个类库不该该把本身组件的初始化以及组装工做交给外部来作。咱们知道经过IOC容器来管理咱们组件的实例化和依赖，其实咱们能够在程序内部实现每个组件，把装配工做交给XML配置进行，可是对于一些复杂的组件，若是这个工做的配置交给XML进行，那么也就至关于交给了使用者进行，至关于须要使用者必定要理解组件内部的装配结构，这是不合理的。更合理的方式是，组件或框架的做者提供一些扩展点，让使用者能够明确经过API来注入本身的扩展组件或实现组件，而对于只须要简单使用组件的使用者能够无需配置开箱即用。

固然，这不是说Spring的IOC和AOP有什么很差，正由于框架实现的如此灵活，Java使用Spring做为容器也基本是标准了，因此Java界不少框架也所以能够相互进行很好的集成，确实是一个很好的平台。

Spring 5推出了Reactive非阻塞技术栈，基于Netty或Servlet 3.1+容器，提供了Stream API、WebFlux以及各类响应式的存储（各类NOSQL）访问类库。从前到后实现非阻塞的服务，能够避免IO阻塞占据线程，减小线程切换和资源使用，以最小的资源作到最大化的并发。惋惜的是JDBC目前并无非阻塞的版本，这样咱们主流的基于MySQL的应用并不能进行全链路（从Controller到外部的Rest服务到数据库）的非阻塞IO（一竿子到底这样才是最爽的）。并且对于Reactive套件，我通过简单的使用我的感受API比较晦涩，链式调用可读性并不高，并且反而遇到了并发的一些坑，加上代码的示例和最佳实践如今也不多，我感到如今使用并非特别成熟。

 

我说Spring Data

 

Spring Data但愿以相对比较一致的Template API来让咱们更方便得使用各类数据存储。我我的不太喜欢习惯使用Data套件而是更喜欢使用各类NOSQL的Java原生客户端。几个缘由：

• 原生客户端紧跟服务端的实现，能够第一时间体验到最新的功能
• 原生客户端的API和服务端提供的API每每一一匹配，能够一竿子到底，让咱们功能使用更准确
• 原生客户端每每只是基于API的简单封装，性能更好

固然，若是咱们只是对NOSQL进行简单使用的话，Spring Data可能使用起来更方便。

 

我说Spring Boot

 

稍微老一点的Java开发基本都是从纯XML配置到XML+注解配置走过来的，比较有意思的是不少开发虽然当初在使用XML配置，可是每每问他们每个配置的含义都不能准确回答出，基本就是拿着主管或前人搭建的一套XML配置直接复制粘贴过来使用。从侧面说明了，其实咱们大部分那些Mybatis、Spring MVC的配置都是在干组件初始化而不是定制化的事情。从0开始要让一个组件用起来就须要这些基本的配置，既然是这样的话，其实彻底能够有默认配置，采用约定大于配置的方式来作。只有在咱们须要针对组件进行定制化的时候才去作更多配置。

Spring Boot不但在自动配置、配置简化上作了不少工做，并且还提供了轻量的嵌入式的容器，只须要20行的Pom+10行代码，就能够当即实现一个能够自启的应用程序（部署简单）激发了咱们使用微服务的热情。此外也给咱们作了不少Production-ready的启示（Actuator），告诉咱们一个完善的应用程序应当注重环境切换、监控、日志、打点等等方面。总之，以前咱们可能须要半天时间搭建一个项目，如今经过start.spring.io甚至只须要10秒。在有Boot以前，我实在没有兴趣使用重量级的Java（可能就为了访问下数据库作一些处理，仍是使用Python算了）来建立一个实验性的控制台应用程序。

 

我说Spring Cloud

 

 

上图来自官网首页，很好地阐述了各个组件之间的关系。咱们来逐一过一下脑图上的那些组件：

• 配置管理Cloud Config：提供了客户端和服务端,客户端的使用方式和Spring完美结合，服务端提供了Git方式和文件方式的数据存储，最新版本也提供了数据库方式。这个配置管理的功能上和以前《朱晔的互联网架构实践心得S1E5：不断耕耘的基础中间件》一文中我探到的那些配置管理的功能差十万八千里。
• 服务发现Netflix Euerka：提供可客户端和服务端（兼管理台），这里的客户端是指服务发现的使用方，其实微服务中的服务在这里是客户端。
• 断路器Netflix Hustrix：提供了客户端API、聚合服务端Tubine和Dashboard网站。
• 服务网关：有Netflix Zuul和Cloud Gateway两种网关能够选择，后者听说性能更好。网关其实就是典型的Filter+Handler的实现机制，经过路由找到合适的Handler，而后调用Pre和Post的各类插件式Filter。
• 调用链跟踪Cloud Sleuth：能够搭配Zipkin使用，功能只能说凑活用。Zipkin的那后台功能上和国内主流互联网实现的Trace后台功能相比仍是太弱了。
• 消息驱动Cloud Stream：抽象成为了产出消息的Source，消费数据的Sink和抓换数据的Processor。而后把Broker的实现经过Binder进行解耦，支持主流的Kafka、KafkaStream和RabbitMQ三种类型。
• 消息总线Cloud Bus：抽象了MQ的功能，支持主流的MQ产品。
• 函数即服务Cloud Function：把函数封装为Web服务或Stream服务能够独立调用。对函数编程的Function、Consumer和Supplier分别映射成为了Processor、Sink和Source。
• 微服务契约Cloud Contract：实现契约优先的编程，能够先定义契约对契约进行测试，同时进行服务实现。复杂的服务能够用这套方式来作，消费者提供者对着契约本身编本身的，两不耽误。
• 任务框架Cloud Task：非定时任务的概念，这里的任务是指一次性运行的进程。框架提供了任务执行审计管理最基本的功能。这里的任务最后能够在Cloud Dataflow中运行也能够独立运行。
• 管理台：这里列的Admin管理台是第三方提供的，基于Actuator的端点进行信息的综合展现和监控。

总结一下，整体上我感受Cloud模块化的思想很好，模块和模块之间能够相互搭配使用，可是可能一开始没有进行系统性的规划，版本的升级带来的Breaking Changes有点过多，并且由于内容太多了，文档方面没有特别全面，要所有用起来坑会比较多，须要享受新功能的话还须要不断更新框架版本不断踩坑。

从目前功能的完善程度来讲我感受核心功能完善度在60%（大概还须要发展1年能够用的比较舒服）。后台方面过于简陋，官方提供的后台零散丑陋并且完成度极低（相比国内一线互联网在治理这块开发的功能来讲，完善度大概在30%，大概还须要发展2年能够用的比较舒服，若是能够好好规划一套完整的后台把服务治理全部相关功能都整合在一块儿就行了）。无论怎么样，至少Cloud套件是一套完整的解决方案，目前来看尚未能够媲美的其它开源选择可使用（Dubbo咱们也知道虽然如今又开始高速迭代，可是因为其原始定位是RPC框架，理念上仍是有不少不一样的，组件方面并无Cloud那么完善）。

除了功能不完善，Cloud令我担忧的还有一点是（我没测试过，可是由于看到目前功能的迭代速度对这方面信心不足，谁大规模应用了可否能够给点数据），这些中间件（服务发现、网关服务、链路跟踪、配置管理）是否是通过压测，是否能够知足比较大的压力，若是只是实现功能的话，可能会在全面用起来后遇到性能瓶颈，在这个时候恐怕就麻烦了。

 

总结

Spring家族已是功能强大的庞然大物了，咱们的项目pom中出现几十个Spring依赖也是屡见不鲜。使用.NET家族的套件也是几年前的事情了，可是至今我仍是以为微软.NET的开发套件无论是MVC仍是ORM仍是RPC方面比Spring的MVC、Data JPA（如今你们都使用Mybatis，Mybatis也仍是太弱了）、Cloud套件在功能和设计的优雅上更胜一筹，但愿未来能够看到Spring针对这些点继续发力，而且持续打造Dataflow套件，结合K8S打形成一个微服务的OS（各类中间件能够实现一键部署集群）。另外对于Spring Cloud除了核心功能以外，但愿在管理台方面能够继续完善，打造一个一体化（不必定是一个网站，可是至少能够有权限控制和审计，实现SSO）的管理台，全面实现微服务部署伸缩、服务治理、数据流程管理、服务全链路监控、配置管理等等功能，也期待Spring Cloud和Dataflow双剑合璧在未来的2到3年定义微服务和以数据为核心的流处理的架构标准。