spring cloud alibaba
官方宣布:https://spring.io/blog/2018/10/30/spring-cloud-for-alibaba-0-2-0-released
alibaba 的 spring cloud 生态中,提供了微服务开发中必须要用到的组件,就像 Spring Cloud
一样,通过这些组件以及简化的编程模型使得开发者对于微服务架构的开发变得更简单。
目前 Spring Cloud Alibaba 这个生态中,已经有相对成熟的体系
1. Dubbo, 用于实现高性能 Java RPC 通信
2. Nacos, 服务注册发现、配置管理、服务管理
3. Sentinel, 流量控制、熔断降级、系统负载保护
4. RocketMQ, 分布式消息系统,提供低延时的、高可靠的消息发布与订阅服务
5. Seata, 高性能微服务分布式事务解决方案
6. 【商业】Alibaba Cloud OSS 阿里云对象存储服务(Object Storage Service,简称 OSS),
是阿里云提供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时
间、任何地点存储和访问任意类型的数据。
7. 【商业】Alibaba Cloud SchedulerX 阿里中间件团队开发的一款分布式任务调度产品,支
持周期性的任务与固定时间点触发任务。
8. 【商业】Alibaba Cloud SMS 覆盖全球的短信服务,友好、高效、智能的互联化通讯能力,
帮助企业迅速搭建客户触达通道。
从这去年 Dubbo 加入到 apache 进行孵化,以及阿里对于开源这块的重新重视,我相信 spring
cloud alibaba 未来应该会成为国内主流的微服务解决方案。主要的猜想根据是阿里的技术架
构是经历过无数次双十一的考验,意味着 spring cloud alibaba 有着强大的抗压能力。开源地址
https://github.com/spring-cloud-incubator/spring-cloud-alibaba
项目组成部分
项目由两部分组成,一部分是开源组件,另一部分是云产品
开源组件,它的项目前缀是:spring-cloud-alibaba,它有几下几个特性。
1. 服务发现
2. 配置管理
3. 安全高可用性
云产品项目前缀是:spring-cloud-alicloud,它有几下几个特性。
1. 对象存储服务(OSS)
2. 任务调度(SchedulerX)
3. 日志服务(SLS)
下一代微服务(service Mesh)
有没有同学了解过 Service Mesh。
什么是 Service Mesh?
简单来说,它可以直接翻译成服务网格。它是一个基础设施层,用于处理服务之间的通信,
并且负责请求的可靠传输。什么意思呢?
serviceMesh 演进
在第一代网络计算机系统时代,那个时候的程序员需要完成服务的网络通信,需要自己写代
码来处理网络通信的细节,比如数据包的顺序、流量控制。导致网络处理逻辑和业务逻辑混
合在一起,同时对于开发人员来说要求较高。为了解决这个问题,把网络层的处理逻辑进行
抽象,实现了 TCP/IP 技术。对于用户而言,并不需要关心底层的网络通信环节。
到了微服务时代,我们也面临了类似的问题。业务人员在做微服务开发时需要处理一些列比
较基础的事情,比如服务注册、服务发现、负载均衡、服务熔断和重试等。
这些功能对于每一个业务程序员而言,都必须要了解和掌握,而实际上这些和业务功能并没
有太大的关系,它理应是一个基础组件。
所 以 , 有 些 公 司 就 开 始 开 发 基 础 组 件 , 典 型 的 Netflix OSS 套 件(eureka/hystrix/feign/ribbon/zuul)。有了这些组件,开发人员就可以使用很少的代码来实
现这些服务治理的功能。而恰恰因为这个原因,使得 Spring Cloud 的普及非常快,几乎成了
微服务的代名词
但是到这一步之后,就完美了吗?其实不是, 虽然 spring cloud 这个生态中的各种组件能够
解决微服务开发中的各种问题,但是对于一个业务开发而言,需要掌握这么多的技术组件,
门槛比较高。同时在落地的过程中任何一个组件出现问题,都需要较长的时间来解决。要完
全吃透 Spring Cloud 和 Netflix OSS 的各种套件是很困难的
SpringCloud 微服务带来的问题
业务团队的痛点
1. 对于业务开发团队而言,最强的是技术吗?一定不是,业务团队最强的一定是对于业务的
理解和熟悉程度。
2. 而业务应用的核心价值,就是为了实现业务场景,而不是写微服务,微服务只是一种实现
业务的手段。
3. 业务团队除了关心业务之外,他们所面临的最大的挑战在于,如何保证系统的稳定性何可
扩展性、如何设计一个安全的 open api。如果对服务进行拆分、如何保证跨库的数据一致
性。以及对于旧系统的改造。
4. 于公司层面而言,业务团队的压力还来自于时间人力的投入,我们用于被各种 deadline 赶
着走。所以作为一个业务程序员,如果在这个 deadline 之前还需要花更多的时间投入在
spring cloud 这些工具的学习上,那无疑是雪上加霜。公司对于业务团队的考核,永远只
看结果!
服务治理功能不齐全
SpringCloud 对于服务治理的功能是不够强大的,如果需要实现企业级的微服务落地以及服
务治理,那么我们还需要基于 SpringCloud 这套体系上来解决这些问题。
跨语言带来的问题
微服务有一个很重要的特性,就是不同的微服务可以采用自己最擅长的语言来编写程序。这
种特性在企业中落地的时候又会带来一些问题。
比如公司内部会开发一些公共的类库或者框架,也或者会使用第三方的类库或者框架来实现
某些功能。
但是由于公司的微服务用了各种各样的语言,那意味着这些类库需要针对不同的语言开发兼
容版本。如果是主流语言还好,如果是一些小众语言,那对于这些基础组件的开发者而言无
疑是晴天霹雳
总结
从这些痛点中可以发现,我们所做的所有非业务类的事情,都是为了保证把请求发送到正确
的地方,并且能够及时或得正确的结果。那对于对于业务开发人员而言,是否有必要去关心
这些呢?
回到最开始我们说的一个例子,在进行计算机网络通信的时候,开发人员有必要去关心网络
通信的细节吗? 我们在使用 http 协议进行数据传输时,关心过底层是使用 TCP 还是 udp?
数据是怎么传输的?
既然我们不需要关心这些,那对于微服务架构中的这些问题,业务开发人员为什么一定要关
心服务的通讯呢?
技术栈下沉
那么对于微服务实施来说,能不能像网络协议的下沉一样,增加一个微服务层来完成这个而
是情呢?这就引出了 service mesh
在每个服务中,会有一个 service mesh 实例,客户端发起一个请求,首先会把请求发送到本
地的 service mesh 实例,service mesh 实例中会完成完整的服务之间的调用流程,比如服务
发现、负载均衡。最终发送给目标服务。而这个 service mesh 实例,专业名称应该为:sidecar ,
简单来说,它是原有的客户端和服务端之间的一个代理
在多个服务的调用中,这种通信方式的表现形式就像一个网格,sidecar 之间的链接形成了一
个网络,这个就是 service mesh 的由来