spring cloud gateway使用,spring cloud gateway 路由转发
放弃春云网关！ApacheSix在“还钱”业务上的技术实践_wx630f055ce23fc的技术博客_博客
不同行业之间的业务属性会有一些差距。对于金融领域的应用软件来说，由于涉及到金钱等因素，在业务上会有以下独特的属性：
稳定。金融业与钱强有关，后者对业务稳定性的要求非常严格。稳定性一旦出现问题，就会影响整个交易系统的成败。强监管。强监管一般是针对生物医药、医疗、金融领域，因为它们呈现的内容都与人的生命相关。因此，更高层的强监管要求必然会影响一些业务层的选择和架构呈现。准确性和有效性。因为它与钱强有关，所以数字演示要求零偏差。就像股票价格一样，它的数字表示精确到分分秒秒和固定位数。基于以上特点，金融行业软件系统在系统设计、机房拓扑结构、中间件选择等方面都会与其他一般行业有所不同。
为什么金融系统独爱Java？Java从诞生之日起就受到开发者的喜爱。中国近50%的开发者都在使用Java作为开发语言。这不仅是因为其语言的优势，更是因为Java相关的生态非常巨大。尤其是国内很多财务系统都是基于Java的，导致一段时间以来大家误以为所有系统都是Java做的。
在过去的15 ~ 20年里，大部分金融系统基本上都选择了Java技术栈。探究原因，我们认为主要是因为Java技术栈具有以下优势。
就这样，Java逐渐受到了财务软件系统的青睐。
云原生时代Java地位随着科技行业的快速发展，单一架构逐渐被淘汰，微服务和云原生时代正在全球范围内流行。但在近几年的技术环境下，Java作为面向对象的高级语言，在一些业务场景下也开始略显疲态：
首先，Java的性能低，拿它和C语言相关的技术栈对比一下就明白了。Java是基于虚拟机的，它的内存管理是留给虚拟机的，所以当面对一些高性能或者动态变化的业务场景时，Java语言在处理上并没有那么强。
其次，Java语言需要更多的资源。如果不考虑构建一个架构的成本，很多问题都可以轻松解决。但是，在云原生时代，所有的资源计算变得越来越精细，越来越细粒度。Java在运行中需要消耗大量的资源。由于其沉重的组件和需要重新启动的基本功能，该语言在高QPS或高业务连续性需求的场景中更容易出现问题。
最后，指针变量的问题。习惯写C/C语言的同学都知道，指针是一个非常好的资源。然而，Java是基于虚拟机的，它将内存管理交给GC(垃圾收集)而不是手动程序。所以对于一些高并发、高访问、高性能的特定情况或场景，Java的实际性能可能会略显不足。
为什么选择APISIX？数字技术是提供智能金融的服务平台。其主要产品包括还钱和赏花。12在业务架构层面，环百的产品实现一直依赖于Java技术栈。
Spring Cloud Gateway是Spring Cloud生态中诞生的一个网关项目，用来更好地管理微服务。当Java是公司业务的主要开发语言时，Spring Cloud Gateway通常是一个很好的API网关选择。但是在API gateway最近的迭代中，放弃了使用已久的Spring Cloud Gateway，转而选择了Apache APISIX。
架构前后的变化是架构层面的，使用APISIX前后的变化如下图所示。
在左侧的预使用架构中，使用了三套网关系统，网关分为两类：入口网关和出口网关。其中，在操作系统网关和导出系统网关中使用Spring Cloud Gateway作为网关，在业务系统网关中使用OpenRestry作为业务系统网关。
最初使用Spring Cloud Gateway作为运营导出系统的网关，主要是因为其庞大的生态系统和简单易部署易维护的分布式系统开发框架。所以在业务架构部署的前期，选择了春云家族桶来更快的搭建业务。
但是随着业务的缓慢发展，原有架构下网关的一些稳定性问题开始显现，比如内存溢出、CPU利用率高等。为了升级网关的性能，统一多个网关，架构中的所有网关统一替换为Apache APISIX。
在新的网关架构中，业务系统的网关将优先通过服务发现将请求流量直接转发到业务系统。如果后端应用程序在Consul中没有健康的Pod，或者后端应用程序不支持服务发现，等等。它会将流量转发到之前的内部网络K8s入口，以用作底部的上游。
新架构还统一了导出网关的两个应用，新的导出网关部署在K8s集群外的外联区域。同时在出口网关集群前增加一个SLB，可以统一出口网关的入口，方便在VPC没有服务发现能力或者其他系统调用的应用。
基于APISIX的应用实践在实际业务情况中，内部有很多网关架构，Apache APISIX不能直接使用，所以基于APISIX做一些修改和构建。
APISIX内部构建部署开发时，APISIX网关的代码和自定义代码存储在不同的路径中，两者协同工作，可以独立迭代。部署时采用Docker镜像进行部署，构建APISIX指定版本的基础镜像，然后封装自定义代码形成新镜像。
自定义代码打包时，不使用lua_package_path指定代码目录，而是直接覆盖基础映像apisix的源文件目录，如果有同名文件，则覆盖源文件。Dockerfile如下：
来自registry.xxx.net:5001/apisix-shuhe:v1.5
ENV APP_NAME={{APP_NAME}}
复制{ {产品文件}} /tmp/deploy2/artifact.tar.gz
运行mkdir/tmp/deploy/tar-xf/tmp/deploy 2/artifact . tar . gz-C/tmp/deploy/\
CP-R/tmp/deploy/API six//usr/local/API six/\
CP/tmp/deploy/bin/API six/usr/bin/API six \
CP/tmp/deploy/conf/API six-$ APP _ name . YAML/usr/local/API six/conf/API six . YAML \
CP/tmp/deploy/conf/config-$ APP _ name . YAML/usr/local/API six/conf/config . YAML \
set -x \
bin=#！/usr/local/openresty/Lua JIT/bin/Lua JIT \ n package . path=/usr/local/API six/？lua .package.path \
sed -i 1s”。*@$bin@ /usr/bin/apisix \
rm -rf /tmp/*APISIX的日志默认存储在本地(也可以通过Syslog等插件收集)。通过调整nginx配置模板和判断启用的配置文件来决定日志是存储在本地还是通过Syslog存储在FLUENTD中。同时，模板中的FLUENTD_HOST变量在构建镜像时被替换。如下所示：
{ % if GW _ profile and string . find(GW _ profile， local) then %}
access _ log logs/access . log main；错误日志日志/
error.log警告；
{%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无法将一个域名的流量转发到两个命名空间的路由上，所以考虑将新网关部署在与旧网关相同的命名空间中。即在域名的路由下挂载多个服务，然后通过路由调整流量比例，控制流量是去新网关还是旧网关。
具体实现过程如下图所示。在旧网关的命名空间下添加C组和D组部署新网关，通过路由控制新老网关的流量比例。
Java网关的考虑事项很多Java工程师在微服务架构上会选择Spring Cloud，主要是语言绑定，以类库的形式放在代码里。但是，在实践中可能很难升级。如果团队是多语言的，就需要维护多个类库。假设有10个版本，10种语言，需要维护100个类库。
这时候多版本多语言的问题就可以通过代理(即API网关)轻松解决了。选择APISIX作为API网关后，Java技术栈有什么好处？根据我们的实践经验，从以下两个角度进行了总结。
公司观点1\。功能和性能都不错。APISIX的QPS可以达到80K，使用4核虚拟机，不需要插件，很好的解决了Spring云网关在接受C端流量时的性能问题。而且在生产环境中发现，APISIX比之前的网关提高了30%以上的性能。
其次，得益于云的原生属性，APISIX完全可以满足公司在实际测试中的需求，如认证、可观测性、服务发现、电流和速度限制、四层和七层流量转发等。在功能扩展方面，APISIX也支持70多个插件，大部分业务都可以使用其原生插件，大大减少了开发工作。
2\.企业支出成本下降。在使用APISIX之前，如果出现性能瓶颈，公司只能通过不断增加服务器来解决这个问题，所以相应的硬件成本会非常高。
白在成本计算中还发现，使用APISIX后，服务器数量减少了60%左右。技术栈统一后，业务可以轻松实现基于APISIX原生框架的功能扩展，节省了开发成本，加快了项目上线时间。
开发者角度1\。满足业务需求。业务中使用的所有软件或技术都应该满足需求。从实际测试结果和调查数据来看，APISIX的稳定性、可观测性和可扩展性会更好。
软件最终服务于业务。如果业务需要为公司节省资源，那么无论公司的技术栈是什么，都会使用最适合公司业务的组件。
2\.降低维护成本相比之前的OpenResty，APISIX的学习成本相对较低，维护起来更省心。同时，APISIX丰富的插件简化了一些通用功能的实现和部署，大大节省了项目上线的时间。
同时，借助APISIX强大的日志记录和动态调试功能，业务可以轻松找出故障点，从而快速定位，节省时间。
总结：金融业务发展趋势在过去的十年里，互联网金融逐渐从“野蛮生长”转变为“精耕细作”，而这种转变主要涉及到制度的变革。
野蛮生长阶段，商业讲究效率。为了更快地构建业务，在选择基础设施时，负责人更有可能选择自己熟悉的语言架构来构建。不同的主体会选择使用不同的技术栈，从而留下很多技术债。从2017年开始，大部分仍然活跃的金融企业或服务公司将面临同样的技术现状，即存在多套技术组件。这时候就需要统一基础设施了。
当涉及到精耕细作时，企业需要对系统进行纵向拆分，从之前的烟囱式拆分为前中后台模式。当系统达到稳定阶段时，需要夯实一些东西。
制度建设的根本目的其实是为了共享。重复使用越多，系统的运维成本越低。所以很多公司都到了精耕细作的阶段，要么垂直拆分系统，要么下沉基础组件，以此来控制运维成本。
作为企业，成本优先还是要考虑的一个原则。在野蛮生长阶段，可能只需要尽快实现业务，但在目前的环境下，成本优先肯定在预算之内。这样，效率和成本只能永远节省。所以在成本有限的情况下，企业会少谈技术的先进性。在技术人员选择的过程中，他们不会考虑目前选择的技术对团队有多大影响，对现有运维架构有多大好处等。但更多的是从成本的角度。
版权归作者所有：原创作品来自博主小二上九8，转载请联系作者取得转载授权，否则将追究法律责任。
郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。