精选列表

搜索[SpringCloud]，共1270篇文章
优秀的个人博客,低调大师
2022-10-10

放弃 SpringCloud Gateway！Apache APISIX 在「还呗」业务中的技术实践

不同行业之间，都会存在一些业务属性上的差距。对于金融领域的应用软件来说，因其涉及到钱等因素，所以在业务上会有以下独特属性： 稳定性。 金融领域跟钱强相关，这对于业务稳定性就有着非常严格的要求，稳定性一旦出现问题，它将影响整个交易系统的成败。 强监管。 强监管一般是针对生物医药领域、医疗领域和金融领域，因为它们所呈现的内容都与人的生命相关。所以，更高层面的强监管要求势必会影响一些业务层面的选型和架构呈现。 准确性和有效性。 由于跟钱强相关，所以在数字层面的呈现更是要求零偏差。就像股票价格一样，它的数字呈现都是精确到了每分每秒和固定数位的。 基于以上这些特点，金融行业软件系统在进行系统设计、机房拓扑以及中间件选型时，就会出现一些与其他通用行业不太一样的地方。 对 Java 的那些爱与恨 金融系统为何独爱 Java Java 自诞生以来就深受开发者的喜爱。在中国有将近 50% 的开发者在使用 Java 作为开发语言。这不单单是因为其语言的优势，也因为 Java 相关的生态非常庞大，尤其是国内的金融系统很多都是基于 Java 的，这导致有段时间大家都误以为所有的系统都是用 Java 做的。 近 15～20 年以来，大部分金融系统基本都选择了 Java 技术栈，深究其原因，我们认为主要是因为 Java 技术栈有以下几点优势。 正是如此，Java 逐渐得到了金融类软件系统的青睐。 云原生时代下的 Java 现状 随着技术行业的快速发展，单体架构逐渐被淘汰，微服务和云原生时代正在风靡四海。然而在近几年的技术大环境下，作为面向对象的高级语言，Java 也在一些业务场景中开始略显疲惫： 首先，Java 性能较低，这点对比一下 C 语言相关技术栈就会明白。Java 是基于虚拟机，它的内存管理是交给虚拟机来解决的，所以当面对一些高性能或动态变化的业务场景时，Java 语言在处理上没有那么强势。 其次，Java 语言需要更多的资源。一个架构的打造如果不考虑成本，很多问题都很好解决，但在云原生时代下，所有的资源计算变得越来越细、越来越颗粒化。Java 在运作时需要消耗大量的资源，由于 Java 分量重和需要重启的基础特性，因此在高 QPS 或者业务连续性要求较高的场景下，该语言会更容易出现问题。 最后就是指针变量的问题。习惯于写 C/C++ 语言的同学都知道，指针是一个非常好的资源。但 Java 是基于虚拟机，它把内存管理交给了 GC（Garbage Collection），而不是由手动程序进行管理，所以对于一些特定情况或者高并发、高访问量和高性能的场景下，Java 的实际性能可能就略显不足了。 还呗为何选择 APISIX？ 数禾科技是一家提供智能化金融的服务平台，旗下主要产品有还呗、还享花等。还呗 APP 是一款基于消费多场景的分期服务平台，通过与持牌金融机构合作，为大众提供个人消费信贷服务，并为小微企业主提供贷款资金支持。在业务架构层面，还呗的产品实现一直是依赖 Java 技术栈的。 Spring Cloud Gateway 是 Spring Cloud 生态下为更好管理微服务而诞生的网关项目，对于公司业务以 Java 为主要开发语言的情况下，Spring Cloud Gateway 通常是个不错的 API 网关选择。但在近期的 API 网关迭代过程中，还呗放弃了使用已久的 Spring Cloud Gateway，而是选择了 Apache APISIX。 架构的前后变化 在架构层面，还呗在使用 APISIX 前后呈现了如下图所示的变化。 在左侧的使用前架构中，还呗一共使用了三套网关系统，并把网关分为入口网关和出口网关两大类。其中在运营系统网关和出口系统网关中，都使用了 Spring Cloud Gateway 作为网关，而在业务系统网关中则使用了 OpenRestry 作为业务系统网关。 对于一开始使用 Spring Cloud Gateway 作为运营和出口系统网关，主要是看中了 Spring Cloud 庞大的生态系统，以及简单易部署和易维护的分布式系统开发框架，所以在早期进行业务架构部署时，为了更快搭建起业务而选择使用 Spring Cloud 全家桶。 但随着业务慢慢发展，原先架构中的网关开始出现一些稳定性的问题，比如内存溢出、CPU 使用率过高等情况。为了升级网关性能及统一多个网关，还呗将架构中的网关全部统一替换为了 Apache APISIX。 在新网关架构中，业务系统网关会优先把请求流量通过服务发现的方式直接转发到业务系统。如果后端应用在 Consul 中没有健康 Pod 或者后端应用不支持服务发现等，就会把流量转发到以前的内网 K8s Ingress，作为兜底的上游来使用。 新架构同时也统一了出口网关的两个应用，新出口网关部署在 K8s 集群外的外联区。同时也在出口网关集群前新增一个 SLB，可以统一出口网关的入口 ，方便没有服务发现能力的应用或者其他 VPC 内的系统调用。 基于 APISIX 的应用实践 实际业务情况下，由于内部已存在多种网关架构，没办法直接使用 Apache APISIX，于是还呗基于 APISIX 进行了一些改造和构建。 APISIX 构建部署 在内部进行开发时，将 APISIX 网关的代码和定制代码存放在不同路径下，两者协同工作，各自可独立迭代。在部署时则采用 Docker 镜像方式部署，构建一个 APISIX 指定版本的基础镜像，然后再把自定义代码打包形成新镜像。 自定义代码打包时没有使用 lua_package_path 来指定代码目录，而是直接覆盖基础镜像 apisix 源码目录，如果有同名文件则覆盖源码文件。Dockerfile 如下所示： FROM registry.xxx.net:5001/apisix-shuhe:v1.5 ENV APP_NAME={{APP_NAME}} COPY {{PRODUCT_FILE}} /tmp/deploy2/artifact.tar.gz RUN mkdir /tmp/deploy/ && tar -xf /tmp/deploy2/artifact.tar.gz -C /tmp/deploy/ && \ cp -R /tmp/deploy/apisix/ /usr/local/apisix/ && \ cp /tmp/deploy/bin/apisix /usr/bin/apisix && \ cp /tmp/deploy/conf/apisix-$APP_NAME.yaml /usr/local/apisix/conf/apisix.yaml && \ cp /tmp/deploy/conf/config-$APP_NAME.yaml /usr/local/apisix/conf/config.yaml && \ set -x && \ bin='#! /usr/local/openresty/luajit/bin/luajit\npackage.path = "/usr/local/apisix/?.lua;" .. package.path' && \ sed -i "1s@.*@$bin@" /usr/bin/apisix && \ rm -rf /tmp/* APISIX 的日志默认存储在本地（也可以通过 Syslog 等插件收集），通过调整 nginx 配置模板和判断启用的 Profile 来决定日志存储在本地还是通过 Syslog 存储到 FLUENTD 中。同时在构建镜像时替换模板中 FLUENTD_HOST 变量。如下所示： {% if gw_profile and string.find( gw_profile,'local') then %} access_log logs/access.log main;error_log logs/ error.log warn; {%else%} access_log syslog:server=${FLUENTD_HOST}:5141 json_format; error_log syslog:server=${FLUENTD_HOST}:5142 warn; {%end%} 在 nginx 配置模板中，还呗不光修改了日志存储，还调整了循环添加 ENV 环境变量、循环添加 lua_shared_dicts 配置及写死一些 NGINX 其他调优参数。 因为公司是按照业务流量划分为多种网关，这些网关的基本功能都差不多，因此还呗内部采取了「一套代码部署多个网关应用」方案。通过 Profile 功能配置各个网关的 config-xxx.yaml 文件，然后通过公司 DEVOPS 平台构建镜像时，根据应用名构建不同网关的 Docker 镜像即可。 公司级定制插件 在内部访问运营系统页面时，会调用很多后端的 API 获取数据，这些 API 都需要在 API 网关中配置对应的白名单。在页面中根据登录运营系统用户的角色不同，能够访问的 API 范围也不一样，因此权限系统也需要维护相关 API 列表。每当在页面上新增后端 API 调用时 ，都需要开发人员在网关页面及权限系统页面配置两次，工作冗余且重复。 为此，还呗把网关配置与权限系统配置打通，只保留权限配置系统的配置入口，网关配置管理系统则定时拉取权限 API，之后转换成网关 API 白名单配置。这样做不仅能减少用户一次配置操作，同时也协助权限系统进行了权限管控。可以保证在运营页面调用的后端 API，一定是在权限系统配置了相关权限。 在公司的实际业务中，经常会遇到原生插件不能满足实际需求的情况，就需要定制开发。好在 APISIX 提供了很多工具类，参照原生插件就可以轻松实现，开发过程也非常简单。以下列举了还呗内部基于 APISIX 进行的其他定制插件： 网关流量灰度 之前还呗使用的 K8s 容器是 OpenShift（现已升级为 ACK 集群），其中 Ingress 是 Haproxy 搭建。由于公网 K8s Ingress 的 Haproxy 不能把一个域名的流量转发到两个 Namespace 的路由中，因此考虑把新网关部署在和老网关相同的 Namespace 下。即域名的路由下挂载多个服务，之后便可以通过路由调整流量比例，控制流量走新网关还是老网关。 具体实施流程如下图所示，在老网关的 Namespace 下新增 c、d 组用于部署新网关，通过路由控制新老网关的流量比例。 Java 层面网关的考虑因素 很多 Java 工程师在微服务架构中都会选择 Spring Cloud，主要是语言绑定，并用类库的方式放在代码里。但是在实践过程中可能会出现升级困难的情况，如果团队是多语言就需要维护多个类库，假设有 10 个版本与 10 种语言，就需要维护 100 个类库。 此时就可以通过代理的方式（即 API 网关）把多版本和多语言的问题轻松解决。那 Java 技术栈公司选择 APISIX 作为 API 网关后都有哪些收益？我们根据还呗的实践经历，从以下两个角度进行了总结。 公司角度 功能与性能兼具 还呗在内部使用 4 核虚拟机无插件空跑压测 APISIX 的 QPS 可以达到 80K，很好地解决了 Spring Cloud Gateway 在承接 C 端流量时出现的性能问题，而且在生产环境中发现 APISIX 相较于之前网关性能提升了 30% 以上。 其次，得益于云原生属性，APISIX 在实际的测试中完全可以满足公司的需求，比如认证鉴权、可观测性、服务发现、限流限速以及四层和七层流量转发。而在功能扩展方面，APISIX 也支持了 70 余款插件，大部分的业务可以使用其原生插件，很大程度上减少了开发工作。 业务支出成本下降 在使用 APISIX 之前，如果性能出现了瓶颈，公司只能通过不断的增加服务器来解决这个问题，因此相应的硬件成本也会非常的高。 还呗在进行成本计算时发现，使用 APISIX 后，服务器的数量大概减少了 60% 左右。统一技术栈后，业务上也可以很轻松地基于 APISIX 原生框架实现功能的扩展，节省了开发成本，加快了项目上线时间速度。 开发者角度 满足业务需求 业务中所使用的软件或技术都应该是为需求而服务。从实际测试结果及调研数据来看，APISIX 的稳定性、可观测性、可扩展性会更好。 软件最终服务于业务。如果业务需要，可以为公司节约资源，那么无论公司的技术栈是什么，都会使用最符合公司业务的组件。 降低维护成本 相比之前使用的 OpenResty，APISIX 的学习成本相对较低，维护起来也比较省心。同时，APISIX 丰富的插件简化了一些通用功能的实现与部署，大大节约了项目上线的时间。 同时利用 APISIX 强大的日志和动态调试功能，业务可以很轻松地排查出故障点，从而快速定位、节约时间。 总结：金融业务发展趋势 在过去的十年里，互联网金融从「野蛮生长」开始逐渐向「精耕细作」模式转变，这个转变主要涉及到的就是系统的变革。 在野蛮生长阶段，业务讲究的是效率。为了业务更快速地建设，在基础架构选择的时候，负责人更多是选择自己熟悉的语言架构进行搭建。不同的负责人便会选择使用不同的技术栈，因此留下了很多技术债务。从 2017 年开始，依旧活跃的金融企业或服务公司大多都会面临同样的技术现状，那就是存在多套技术组件。这时就需要进行基础设施的统一。 来到精耕细作阶段，企业就需要对系统进行垂直拆分，由以前的烟囱式拆分成前台、中台及后台等模式。系统到达一个稳定阶段时，就需要把一些东西夯实下来。 而系统建设的根本目的其实就是为了共用。重复性使用越强，系统的运维成本就越低。所以很多公司到了精耕细作阶段，要么是进行系统的垂直拆分，要么就是进行基础组件的下沉，进而控制运维成本。 作为企业来说，成本优先依旧是需要考虑的原则。野蛮生长阶段可能只需要尽快实现业务，而在目前大环境下，预算范围之内肯定是成本优先。这样的话，效率和成本永远只能保住一项。因此在成本有限的情况下，企业就会少谈技术的先进性。技术人员在选型的过程中，就不会考虑当下选择的这个技术对团队有多大冲击、对现有的运维和架构带来多少收益等等，更多是从成本角度考虑。
优秀的个人博客,低调大师
2022-09-12

Dante Cloud 2.7.3.4 发布, SpringCloud升级2021.0.4支持多租户

Dante Cloud 是一款企业级微服务架构和服务能力开发平台。首个全面拥抱 Spring Authorization Server 的版本，基于Spring Boot 2.7.3、Spring Cloud 2021.0.4、Spring Cloud Alibaba 2021.0.1.0、 Spring Authorization Server 0.3.1、Nacos 2.1.1 等最新版本开发的多租户系统，遵循SpringBoot编程思想，高度模块化和可配置化。具备服务发现、配置、熔断、限流、降级、监控、多级缓存、分布式事务、工作流等功能 平台定位 构建成熟的、完善的、全面的，基于 OAuth2.1 的、前后端分离的微服务架构解决方案。 面向企业级应用和互联网应用设计开发，既兼顾传统项目的微服务化，又满足互联网应用开发建设、快速迭代的使用需求。 平台架构使用微服务领域及周边相关的各类新兴技术或主流技术进行建设，是帮助快速跨越架构技术选型、研究探索阶段的利器。 代码简洁规范、结构合理清晰，是新技术开发应用的典型的、综合性案例，助力开发人员对新兴技术的学习和掌握。 [1]、特别说明 Dante Cloud (但丁，原 Eurynome Cloud) 正式加入 Dromara 开源社区。Dante Cloud 将继续秉承“简洁、高效、包容、务实”的理念，不断地深耕细作、去粗取精，用心打造一款适应未来信息化建设需求的精致产品。同时，与 Dromara 开源社区以及社区中所有的优秀人才一起互相扶持、并肩前行，创造更多、更好、更精的产品以回馈社会，促进软件开源的发展。 谢谢大家对 Eurynome Cloud 支持与厚爱，希望大家继续给与 Dante Cloud以及Dromara 开源社区关注与支持 [2]、为什么更名为DanteCloud 原项目名称 Eurynome Cloud，很多朋友都反映名字太长、读起来拗口、不容易记等问题。因此在加入 Dromara 开源社区之际，将名字进行了变更。 Dante，即但丁·阿利基耶里(公元1265年-公元1321年)，13世纪末意大利诗人，现代意大利语的奠基者，欧洲文艺复兴时代的开拓人物之一，以长诗《神曲》(原名《喜剧》)而闻名，后来一位作家叫薄伽丘将其命名为神圣的喜剧。 他被认为是中古时期意大利文艺复兴中最伟大的诗人，也是西方最杰出的诗人之一，最伟大的作家之一。恩格斯评价说：“封建的中世纪的终结和现代资本主义纪元的开端，是以一位大人物为标志的，这位人物就是意大利人但丁，他是中世纪的最后一位诗人，同时又是新时代的最初一位诗人” 更名为 Dante Cloud，寓意本项目会像恩格斯对但丁的评价一样，在行业变革的时期，可以成为一款承上启下，助力企业信息化建设变革的产品。 [3]、本次更新内容 重要更新 [升级] Spring Cloud 版本升级至 2021.0.4 [升级] Skywalking Agent 版本升级至 8.12.0 [新增] 基于 JPA 的多租户系统支持，支持 Database 和 Schema 两种模式，可通过配置进行开启和关闭。 [重构] 基于 JetCache 的自定义 Hibernate 二级缓存，支持多租户模式下数据的分布式多级缓存。 [重构] 重构前端详情页面参数的传递方式，解决 vue-router 自 4.1.4 版本不再建议使用 push param 传递参数而导致的新增、编辑功能不可用问题。 其它更新 [优化] 优化部分代码日志输出内容及日志输出级别 [优化] 优化基于 JetCache 的 Hibernate 二级缓存代码 [升级] 升级 antisamy XSS 防护配置文件 [修复] 临时修复 BPMN.js 在线工作流编辑器，在第一次加载页面时抛错无法显示 Canvas 和 Property Panel 问题。 [修复] 第三方社交登录 logo 在生产环境下无法正常显示问题。 [优化] 优化服务配置，将第三方社交登录相关配置移至 Nacos 方便修改。 依赖更新 antisamy 版本升级至 1.7.1 hutool 版本升级至 5.8.6 tencentcloud-sdk-java-sms 版本升级至 3.1.590 fastjson2 版本升级至 2.0.13 alipay-sdk-java 版本升级至 4.33.39.ALL [4]、Dante Cloud 2.7.X 主要变化 基于 Spring Authorization Server 深度定制: 基于 Spring Data JPA，重新构建 Spring Authorization Server 基础数据存储代码，替代原有 JDBC 数据访问方式，破除 Spring Authorization Server 原有数据存储局限，扩展为更符合实际应用的方式和设计。 基于 Spring Authorization Server，在 OAuth 2.1 规范基础之上，增加自定义“密码”认证模式，以兼容现有基于 OAuth 2 规范的、前后端分离的应用。 基于 Spring Authorization Server，在 OAuth 2.1 规范基础之上，增加自定义Social Credentials 认证模式，支持手机短信验证码、微信小程序、第三方应用登录。 遵照 Spring Security 5 以及 Spring Authorization Server 的代码规范，进行 OAuth2 认证服务器核心代码的开发，遵照其使用 Jackson 反序列化的方式， 增加大量自定义 Jackson Module。 支持 Spring Authorization Server 的标准的Token加密校验方式外，还了增加支持自定义证书的 Token 加密方式，可通过配置动态修改 支持 OAuth2 OIDC 认证模式，补充前端 OIDC 认证相关配置操作，以及对应的 /userinfo 接口调用支持 和 客户端注册支持 支持 OAuth2 Authorization Code PKCE 认证模式 扩展 Spring Authorization Server 默认的 Client Credentials 模式，实现 Refresh Token 的创建。 扩展 Spring Authorization Server 默认的 Client Credentials 模式，实现真正的使用 Scope 权限对接口进行验证。 增加客户端 Scope 的权限配置功能，并与已有的用户权限体系解耦 自定义 Spring Authorization Server 授权码模式登录认证页面和授权确认页面，授权码模式登录采用数据加密传输。支持多种验证码类型，暂不支持行为验证码。 基于Spring Authorization Server和JPA构建支持Database和Schema模式的多租户架构。 代码结构的大规模调整和优化： 对原有代码进行了深度的“庖丁解牛”，严格遵照“单一职责”原则，根据各个组件的职责以及用途，将整个工程拆解细化为多个各自独立组件模块，在最大程度上降低代码间的耦合，也更容易聚焦和定位问题。 将通用化组件提取为独立工程，独立编译、按需选用，极大的降低系统主工程代码量。相关组件也已上传至 Maven 中央仓库，降低系统主工程工程代码编译耗时，改进和提升 CICD 效率， 原有主工程代码结构也进行了深化调整，代码分包更加合理，代码逻辑也更加清晰。 [5]、界面预览 [6]、额外说明 本项目以后将主要维护 `Spring Authorization Server` 版本，原有基于 `Spring Security OAuth2` 的版本已经移至 spring-security-oauth2 分支，可以从该分支或发行版页面获取历史版本继续使用。后期会根据 ISSUE 以及使用用户反馈情况，再行决定是否继续维护 `Spring Security OAuth2` 版本。 基于 Vue3、Vite3、Quasar2、Pinia 等新版前端已发布，原有基于 Vue2、Vuetify2、Typescript 开发的前端代码已移至 vue2+vuetify2+typescript 分支 自 2.7.2.3 版本起，Dante Cloud 所有核心代码全部开源。新开放内容包括： 接口权限鉴权：全面整合 `@PreAuthorize` 注解权限与 `URL` 权限，通过后端动态配置，无须在代码中配置 `Spring Security` 权限注解以及权限方法，即可实现接口鉴权以及权限的动态修改。采用分布式鉴权方案，规避 Gateway 统一鉴权的压力以及重复鉴权问题 动态权限数据分发：采用分布式服务独立鉴权方案，`Spring Security` `@PreAuthorize` 的权限注解、权限方法以及 `URL` 权限，通过后端动态配置后，实时动态分发至对应服务。 User 数据策略访问：`OAuth2` `UserDetails` 核心数据支持直连数据库获取和 `Feign` 远程调用两种模式。`OAuth2` 直连数据库模式性能更优，`Feign` 访问远程调用可扩展性更强。可通过配置动态修改采用策略方式。 手机短信验证码注册认证：采用自定义 `OAuth2` 授权模式，使用统一 `Token` 接口，实现手机验证码登录认证，与平台为统一体系，统一返回`OAuth2` Token，支持服务接口鉴权 第三方系统社交注册认证：集成 `JustAuth`，采用自定义 `OAuth2` 授权模式，使用统一 `Token` 接口，实现基于 `JustAuth` 实现第三方系统社交登录认证，与平台为统一体系，统一返回 `OAuth2` Token，支持服务接口鉴权。所有 `JustAuth` 支持的第三方系统均支持。 微信小程序注册认证：采用自定义 `OAuth2` 授权模式，使用统一 `Token` 接口，实现支持微信小程序登录认证，与平台为统一体系，统一返回 `OAuth2` Token，支持服务接口鉴权。 其它方式注册认证：采用策略模式对外部系登录认证和用户注册进行接入支持，采用 `OAuth2` 默认认证接口。目前未集成的外部系统，可参考标准，适当增减参数，即可支持接入。 多通道 SMS 集成：集成阿里，百度，中国移动，华为，京东，极光，网易，七牛，腾讯，又拍，云片等平台短信发送通道。可通过配置动态选择具体使用通道。支持多模版定义以及模版参数顺序控制 微信小程序订阅消息：支持微信小程序订阅消息发送。提供订阅消息模版工厂，可根据自身业务需求，编写少量代码既可以拓展支持新订阅消息模版。 Dromara开源社区 一、社区愿景 让每一位开源爱好者，体会到开源的快乐。 二、社区官网 https://dromara.org 是 Dromara 开源社区官方网站。 三、成员项目

资源下载

更多资源
Mario，低调大师唯一一个Java游戏作品

Mario，低调大师唯一一个Java游戏作品

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

Oracle Database，又名Oracle RDBMS

Oracle Database，又名Oracle RDBMS

Oracle Database，又名Oracle RDBMS，或简称Oracle。是甲骨文公司的一款关系数据库管理系统。它是在数据库领域一直处于领先地位的产品。可以说Oracle数据库系统是目前世界上流行的关系数据库管理系统，系统可移植性好、使用方便、功能强，适用于各类大、中、小、微机环境。它是一种高效率、可靠性好的、适应高吞吐量的数据库方案。

Eclipse（集成开发环境）

Eclipse（集成开发环境）

Eclipse 是一个开放源代码的、基于Java的可扩展开发平台。就其本身而言，它只是一个框架和一组服务，用于通过插件组件构建开发环境。幸运的是，Eclipse 附带了一个标准的插件集，包括Java开发工具（Java Development Kit，JDK）。

Java Development Kit(Java开发工具)

Java Development Kit(Java开发工具)

JDK是 Java 语言的软件开发工具包，主要用于移动设备、嵌入式设备上的java应用程序。JDK是整个java开发的核心，它包含了JAVA的运行环境（JVM+Java系统类库）和JAVA工具。

热门标签
Docker Nacos 服务网格 HarmonyOS NEXT K8s SpringCloud SpringBoot Redis Jdk25 DeepSeek ChatGPT

欢迎您！

登录后，您将获得更多功能！

热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273