不同行业之间，都会存在一些业务属性上的差距。对于金融畛域的应用软件来说，因其波及到钱等因素，所以在业务上会有以下独特属性：
- 稳定性。金融畛域跟钱强相干，这对于业务稳定性就有着十分严格的要求，稳定性一旦呈现问题，它将影响整个交易系统的成败。
- 强监管。强监管个别是针对生物医药畛域、医疗畛域和金融畛域，因为它们所出现的内容都与人的生命相干。所以，更高层面的强监管要求势必会影响一些业务层面的选型和架构出现。
- 准确性和有效性。因为跟钱强相干，所以在数字层面的出现更是要求零偏差。就像股票价格一样，它的数字出现都是准确到了每分每秒和固定数位的。
基于以上这些特点，金融行业软件系统在进行零碎设计、机房拓扑以及中间件选型时，就会呈现一些与其余通用行业不太一样的中央。
对 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 "[email protected]*@[email protected]" /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 年开始，仍旧沉闷的金融企业或服务公司大多都会面临同样的技术现状，那就是存在多套技术组件。这时就须要进行基础设施的对立。
来到精耕细作阶段，企业就须要对系统进行垂直拆分，由以前的烟囱式拆分成前台、中台及后盾等模式。零碎达到一个稳固阶段时，就须要把一些货色夯实下来。
而零碎建设的基本目标其实就是为了共用。重复性应用越强，零碎的运维老本就越低。所以很多公司到了精耕细作阶段，要么是进行零碎的垂直拆分，要么就是进行根底组件的下沉，进而管制运维老本。
作为企业来说，老本优先仍旧是须要思考的准则。横蛮成长阶段可能只须要尽快实现业务，而在目前大环境下，估算范畴之内必定是老本优先。这样的话，效率和老本永远只能保住一项。因而在老本无限的状况下，企业就会少谈技术的先进性。技术人员在选型的过程中，就不会思考当下抉择的这个技术对团队有多大冲击、对现有的运维和架构带来多少收益等等，更多是从老本角度思考。