Spring Cloud Alibaba 微服务框架
1. Spring Based Framework 已经成为事实标准
根据 Jakarta 2019 年的调研报告，Spring Boot 拥有非常高的占比。熟悉 Java 语言的同学，应该对 Spring 框架都不会陌生。其倡导的依赖倒置、面向切面编程等特性已经形成了 Java 语言的事实标准，几乎所有三方框架都会提供对 Spring 框架的支持。
根据 JetBrings 2019 年的调研报告，61% 的用户会选择 Spring Boot 来代替传统的应用服务器。
image
这里有一个很有意思的点，为什么要“代替应用服务器”呢？回顾前面云原生的特点，我们要弹性，要自包含，要独立进程等等。如果此时部署应用还需需要启动应用服务器会将整个依赖层级复杂化。同时，云原生的各种弹性与调度能力，都同传统的应用服务器存在重叠。直接使用 Spring Boot 作为应用启动入口就成为更加“云原生”的选择。
回到微服务&云原生这个场景的下，Spring 提供用来支持开发工作的框架就是 Spring Cloud。
2. Spring Cloud 以微服务为核心的分布式系统构建标准
同样，还是先看下 Spring 是如何定义 Spring Cloud 这套框架的：
Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, global locks, leadership election, distributed sessions, cluster state). Coordination of distributed systems leads to boiler plate patterns, and using Spring Cloud developers can quickly stand up services and applications that implement those patterns. They will work well in any distributed environment, including the developer’s own laptop, bare metal data centres, and managed platforms such as Cloud Foundry.
这里提到了两个关重要特征：
- 分布式系统中的常见模式
- 任何分布式环境
“分布式系统中的常见模式”给了 Spring Cloud 一个清晰的定位，即“模式”。也就是说 Spring Cloud 是针对分布式系统开发所做的通用抽象，是标准模式的实现。这个定义非常抽象，看完之后并不能知道 Spring Cloud 具体包含什么内容。再来看一下 Spring 官方给出的一个 High Light 的架构图，就可以对这套模式有更清晰的认识：
可以看到这个图中间就是各个 Microservice，也就是我们的这个微服务的实现，周边周围的话就是去围绕这个微服务来去做各种辅助的信息事情。例如分布式追踪、服务注册、配置服务等，都绕微服务运行时所依赖的必不可少的的支持性功能。我们可以得出这样一个结论：Spring Cloud 是以微服务为核心的分布式系统的一个构建标准。
3. Spring Cloud Alibaba 的定位
既然说 Spring Cloud 是标准，那么自然少不了针对标准的实现。这里，为大家介绍下 Spring Cloud Alibaba 这套实现。先给出下面这张图帮助大家理解 Spring Cloud Alibaba 的定位：
这里给大家这么一个公式，这个叫做：“3 加 2”。
3 指的就是图中深色的部分，其实它就是 Spring Cloud 标准，一共有 3 层。中间颜色最深的部分就是及整个微服务最核心的内容，包括了“ RPC 调用”以及“服务注册与发现”。第二层，也就是围绕着核心的这一圈，是一些辅助微服务更好的工作功能，包括了负载均衡、路由、网关、断路器，还有就是追踪等等这些内容。再外层的话，主要是一些分布式云环境里通用能力。
“3 加 2”中的“2”，指的就是上图中最外面这一圈。这一部分就是这个我们 Spring Cloud Alibaba 的一个定义，它其实包含两个部分的内容：
右上部分是对于 Spring Cloud 标准的实现。例如，我们通过 Dubbo 实现了 RPC 调用功能，通过 Nacos 实现了“服务注册与发现”、“分布式配置”，通过 Sentinel 实现了断路器等等，这里就不一一列举了。
左下部分是我们 Spring Cloud Alibaba 对阿里云各种服务的集成。可能很多同学会有这样的一个问题：为什么要加上这一部分呢？此时回头审视一下 Spring Cloud ，它仅仅是一个微服务的一个框架。但是在实际生产过程中，单独使用微服务框架其实并不足以支撑我们去构建一个完整的系统。所以这部分是用阿里帮助开发者完成微服务以外的云产品集成的功能。
这里可能会很多同学会有这么一个担心：是不是使用了 Spring Cloud Alibaba，就会被阿里云平台绑定呢？在此，我们明确的告诉大家，这是不会的。为什么这么说呢？如上面说的，“3 加 2”中的 2 是被分为两个部分的。其中对 Spring Cloud 的实现是完全独立的，开发者可以只是用这部分实现运行在任何云平台中。当然，另一部分，由于天然是对阿里云服务的集成，这部分是和平台相关的。这里给开发者充分的自由，选择只是用其中的部分还是全部产品。当然，我们也非常欢迎开发者选择使用阿里云的全套服务，我们也会尽量保证使用整套产品时的连贯性与开发的便利性。
4. Spring Cloud 各套实现对比
Spring Cloud 作为一套标准，它的实现肯定不止一套，那么各套实现都有什么区别呢？我们来一起看一下下面这张图：
可以发现 Spring Cloud Alibaba 是所有的实现方案中功能最齐全的。尤其是在 Netflix 停止更新了以后，Spring Cloud Alibaba 依然在持续更新和迭代。
从 18 年 7 月份 Spring Cloud Alibaba 正式提交代码开始，就得到了大家广泛的关注。截止今天，Spring Cloud Alibaba 一共获得了超过了 1.5 万的 star 数，已经的领先于所有其他实现的总和。
根据今年 X-lab 开放实验室刚刚发布的《2020 年微服务领域开源数字化报告》，Spring Cloud Alibaba 已经成为最活跃的 Spring Cloud 实现。
数据来源《2020 年微服务领域开源数字化报告》，公众号后台回复关键词“微服务报告”获取报告全文。
5. Spring Cloud Alibaba 生态
作为一个云厂商，我们提供的服务是非常丰富的。可以看到除了围绕着 Spring Cloud 的标准实现以外，还有包括的数据、资源、消息、缓存等各种类型的服务。在不同类型的服务下，也有很多具体的产品可供用户选择。
这里罗列典型而非全部产品。更多的内容，可以参考阿里云官网
6. Spring Cloud Alibaba 用户数
截止到今天，Spring Cloud Alibaba 获得了数超过 1.5w 的 star 数。同时在 Github 上的项目依赖，就是对 Spring Cloud Alibaba 产生依赖关系的产品，也超过了 6000。最重要的，使用 Spring Cloud Alibaba 的公司超过 1000 家。当然不只是外部的公司在使用，我们自己其实也在使用。那经过了双十一的洗礼，其实整个这套框架它的这个稳定性可靠性都得到了印证。
从框架到服务
1. 提供开发者服务，更完整的 Java 开发体验
作为一套框架，Spring Cloud Alibaba 为开发者提供了便捷的编程模型，但是从开发者完整的工作流程上看，是不是还缺点什么？设想一下这样一个场景：作为一个开发者，应该说都做过这样的一个事情，就是从头从零开始去构建一个工程，一直到功能开发这么一个过程的一个过程：
从设计到功能开发，是一个比较长的一个周期的：先要做抽象设计，包括概要设计、架构设计等；然后是一些具象的设计，还有各种框架搭建与架构验证等工作。
在抽象设计阶段，我们要确定整体的架构模式，包括了微服务、Serverless、事件驱动等。以及在这些架构模式下各个应用的领域边界划分。
在具象设计阶段，我们要确定诸如应用分层、分包规则的。这里也有很多的标准可以参考：MVC 分层架构、DDD 领域驱动设计架构等等。在此之后，还有具体的业务模型与接口设计，这些暂不在本文的讨论范围之内。
在实现阶段，需要引入各种框架，并通过配置将这些框架与应用集成起来，完成工程骨架的创建。
最后，还需要将这套骨架运行起来以验证其可行性。
所有上面的工作完成以后，才可以正式的开始业务逻辑实现工作。
在上面的流程里，Spring Cloud Alibaba 能起到的作用是有限的。作为一套框架，为开发者带来的是编程模型上的便利。为了能让开发者更加轻松的完成这一系列流程，我们为大家带来两个重要的产品：“Java 工程脚手架”和 “Sandbox 云沙箱”。
2. Java 工程脚手架：更适合亚太区 Java 开发者的脚手架
很多开发者应该跟我一样，都有过这样的经历：创建新应用时，先找一个我们最熟悉的一个老应用，把它里边的业务代码全部清理干净。然后相关的各种配置名称全部改掉，最终做出一个空的一个应用模板。再把这个应用模板拿过来改个名子，就变成了一个新的应用。
当然可能有的同学会做的更多一些，例如长期维护这么一个空白模板在那里。下次拿过出来之后再改改个名字，就是一个新的应用。
这样做可能是一个相对保险的方案，但是缺点也非常明显：
- 版本老旧，新特性无法享受
- 团队知识无法沉淀
- 重复劳动
我们通过提供 Java 工程脚手架来解决这个问题。下面就是 Java 工程脚手架的页面：
在这里，开发者设置项目的基本信息，例如：开发语言、Java 版本、Spring Boot 版本等内容。
除了基本信息以外，这个平台还提供多种架构模式可供选择。在上图中可以看到，第一个是分层架构，这个是一个很传统的多层架架构模型，包括我们经常说的这种三层架构、五层架构。另一个架构选项是 COLA。COLA 其实是一个典型的一个 DDD 的架构，如果希望在自己团队里边去实践标准的六边形 DDD 架构的话，也是可以去选择他。未来我们可能会去做更多的例如说 MVC 架构，或者是事件驱动的架构模型，提供给大家。
最下边是组价依赖部分，开发者可以在这里选择项目需要使用的组件。这里的选择非常丰富，到从数据库到开发工具、消息、web 等等，一共 100+ 的组价可供大家选择，可以说基本上覆盖了应用开发的所有方面。同时，这里当然不会缺失 Spring Cloud Alibaba 提供的任何组件。
我们希望通过这个工具，尽量减少开发者在创建应用过程中各种查询资料以及繁琐的配置工作。只需要在平台上做一些简单的选择，就可以将工程骨架生成完成。
在 Java 工程脚手架里，除了直接在 WEB 平台配置和下载工程，我们还提供了基于 IDE 的插件，进一步方便用户的使用。
经常光顾 Spring 的同学，应该对这个界面应该非常熟悉，这和 Spring 官方提供的脚手架非常相似。那么我们的工程脚手架和 Spring 官方的实现有什么区别呢？是不是就是对官方功能的镜像呢？我们看一下下面的对比：
区别主要在如下几个方面：
- 样例代码 & 典型配置 ：Spring 官方其实是没有这些样例代码以及配置漏记的。在我们的实现里，会添加这一部分，目前主要覆盖了 Spring Cloud Alibaba 的组件，后面会继续覆盖更多的组件；
- 阿里云组件支持 ：Spring 要保证平台中立的特性，各厂商的组件自然是不会支持的，我们提供 Spring Cloud Alibaba 的全部开源组件和阿里云平台服务组件，同时也会把这些部分独立出来，避免同其他部分的组件揉在一起，影响用户选择；
- 工具链 ：Spring 官方的实现里，例如 IDEA 的插件是专业版里才有，也就是说这是收费的，我们使用 Cloud Tookits 插件实现相关功能，并且完全免费，同时，我们的平台 100% 支持官方插件链接；
- 网络环境 ：Spring 官方服务部署在国外，国内访问不稳定；
- 应用架构 ：这部分在官方实现里是没有的，也是我们未来会重点建设的部分，应用架构在实际生产过程中是不可或缺的。
这套本地化的脚手架也获得了 Spring 官方布道师 Josh Long 的推荐。我们会尽量延续 Spring initiliazr 的产品体验，功能上我们只做增量，同时这个增量给用户保留了充分的选择的自由权益。就是说我们增加这个东西，你可以完全不要，此时整体上和官方提供的产品体验是一模一样的，这是我们整个产品的继续发展会一直坚持的原则。
3. Sandbox 云沙箱：免费、快速验证云产品
第二个服务产品，就是我们的 Sandbox 云沙箱。我们来设想这样一个场景：今天创建一个新的应用，在基础骨架代码开发完成以后，需要去运行它，以验证它的可行性或者是发现其中有没有坑，此时定需要一个运行环境。我如果自己去搭建完整的后台服务运行环境，要么选择从云服务商购买，要么自己本地搭建。这两个选择一个费钱、一个费力。
除了验证新应用的架构，还有很多其他场景也会有类似的困难。例如，需要验证一个云服务产品的可行性，学习相关组价的使用等等。
那么有沒有什么更好的办法呢？这就是 Sandbox 云沙箱需要解决的问题。
这个产品有三个主要的特性：便捷、真实和免费。
- 便捷 ：我们为用户准备了相关代码&开发环境&运行环境，只需要点点鼠标就可以完成整个项目的创建，并部署在我们提供的隔离环境中，中间过程甚至不需要键盘；
- 真实 ：指的是整个产品非常贴近实际工作场景，从开发者角度看，整个项目研发流程，包括代码 checkout / checkin，开发工具，编译流程、部署流程等，使用的都是真实生产流程；从运行时角度看，所有的底层服务使用的都是阿里云提供的真实服务，没有任何单独定制的服务存在；
- 免费 ：所有的服务不会像用户收取费用，甚至所有计费行为的发生，都不会跟用户的账号发生关联。
这套产品支持完整的分布式场景。很多其他的厂商也有类似的产品，但是都只能提供基于单一容器或者主机的案例，这和实际环境中多应用的分布式环境是有差距的。而这个问题，在我们的沙箱产品里是不用担心的。开发者在应用部署后的项目有半小时的使用时间，同时流量&并发数等也会存在一定的限制。
下面来看一下产品的界面：
左边是产品的手册 & 说明部分。这里会包含说当前项目的功能说明、应用架构，以及如何部署和访问这些应用的操作步骤等。一些项目中使用到的技术点以及这些相关知识，也都会在这里呈现给用户。这部分文档的目的，就是方便用户去学习和理解当前的案例。
右边的部分是应用列表。在微服务场景下，一个完整的产品通常需要多个应用组成分布式的集群协同工作。这里就是用来陈列相关的应用列表，同时包含了针对这些应用的操作入口。
图片中的案例是一个任务管理器产品，功能相对简单。但是麻雀虽小五脏俱全。这个产品包含两个应用：
- 一个服务端，的包含了这个任务管理器的所有业务逻辑，以及下层的持久化能力等；
- 一个 WEB 客户端，包含了所有前端页面逻辑、与前端通信的控制器层。
这两个应用通过一个注册中心来实现服务的注册&发现。最终实现一个完整的任务管理器产品。
点击“开发”按钮，打开一个 WEB-IDE 来查看和修改对应应用的代码：
这个 WEB-IDE 和开发者日常使用的 IDE 是一样的，都是左侧代码树，右侧代码编辑器的标准布局。即使是不熟悉这个产品的用户，也可以非常快的上手，甚至不需要学习过程。如果需要部署这个应用，只需要在“运维”功能下，点击“部署”按钮，此时只需要等待部署完成即可。在部署过程会有很多的日志输出，都可以通过“输出”窗体浏览：
部署完成以后，会向 WEB-IDE 返回一个访问地址，开发者只需要点击这和地址就可以访问这个应用。下图是实际的访问效果。可以看到，两个应用，一个是任务管理器的 web 操作页面、一个是后台数据库管理页面：
通过上面的步骤，开发者可以将案例快速部署起来。先部署试用，然后去学习和修改代码，最后再部署验证。通过这样的循环，可以让开发者很快学习和理解案例的功能和相关技术点。
最后再看一下整个沙箱的系统架构流程以及一些关键点：
通过颜色，可以很清楚地看到，沙箱的资源被分为两个部分。蓝色的部分其实是用户独享的资源，包括了：私有代码仓库、部署流程、运行环境等。这一部分在每个用户间相互隔离。尤其是在右下角可以看到，完整的运行环境被隔离在独立的专有网络中。如果是多个应用，这些应用都会链接再同一个网络里边。橙色的部分是公共的资源，这里只有 2 个：案例代码仓库和沙箱后台服务。
第二组概念是：临时资源和长期资源。
临时资源，包括部署流程和运行流程在内。这些资源会在一段时间后会被销毁，从而保证整个产品成本的可控，也避免部分用户对这套产品的滥用。如果需要在资源释放以后，继续使用，只需要重新部署这个应用即可。长期资源的就是会长期存续的资源。可以看到，用户的私有代码仓库就是长期资源。也就是说，无论运行环境是否存续，用户的代码都会一直得到保留。这部分代码，用户可以随时下载到自己本地，并在自己的环境中运行它们。
后续规划
下面是今年，整个 Spring Cloud Alibaba 以及相关服务产品的整体规划：
后续我们会基于 Sandbox 云沙箱上线七天系列课程。通过这个基础知识学习+实操来更好的掌握微服务的相关技术，尤其是对 Spring Cloud Alibaba 的使用。未来还会在沙箱中上线完整的电商商场的案例，包括具有高并发场景的秒杀案例。最后，对 Spring Cloud Alibaba 本身，也会继续建设，集成不少于 20 种阿里云中常用的云产品。进一步提升开发便利性。
如果你对这个产品有进一步了解的兴趣，或者是有什么更好的意见或者建议，欢迎加入微信群（微信搜索：psk12221），一起来交流、吐槽。
网友评论