系统背景与需求
- API网关
传统的金融系统在系统的集成，特别是外部系统的集成上高度依赖以下的几种方式
A. 文件的传输. sFTP或者其变种的安全稳健传输协议
B. 邮件中附件的发送, Excel.
C. 网站页面的浏览，文件的下载
D. SWIFT - 一种银行间的专有信息交换协议
以上的这些方式都不同程度存在着一些共性的问题，就是数据交换不及时，或者协议的复杂且昂贵。 作为金融系统数字还转型的重要组成部分，API网关就成为改变这一切的重要基石。 网关作为和用户连接的一座重要的桥梁，它肩负着安全的验证和授权，请求的转发等重要职责。
- 7*24
金融机构的交易系统都是至关重要的，尤其是一家在全球多数国家都拥有业务的世界500强跨国银行来讲，每时每刻都有可能有用户访问这个系统，所以搭建一套高可用的API网关，当然就是需求之一了。
- Zero Downtime Deployment 持续交付
为了更快地给用户使用到我们开发的功能，解决用户的需求，我们的业务对持续交付的需求越来越强烈。在过去的开发模式中，用户的需求按照瀑布型的开发流程，往往要经历几个月甚至一些大型项目是超过1年的交付周期。而且研发团队也严格按照开发，测试和运维的组织架构完全割裂。执行交付的运维团队往往对研发在过去多个月甚至上年研发的系统不熟悉。现在，我们的研发流程已经完全转型为敏捷，研发团队也不再区分开发，测试与运维团队。我们系统研发人员具备全栈的能力，同时也能发布和运维生产环境的系统。
困难与挑战
- 三层网络隔离 eDMZ, iDMZ, DRN
由于公司对特定级别的应用系统的要求，API网关必须严格按照3层网络隔离的方式部署，分为external DMZ服务，internal DMZ服务和DRN服务。每层之间都由企业级的网络防火墙保护。用户的请求由互联网进入eDMZ之后由反向代理服务器处理，并发送请求到iDMZ。 在iDMZ的反向代理服务器必须对用户的请求进行合法性进行验证，只把符合权限验证的请求发送到DRN的核心业务API。所以，我们在处理持续交付的时候必须很好地处理反向代理服务器的请求，进而达到对用户请求的0影响。
- 异地双活
由于公司对特定级别应用系统的要求，API网关必须部署到异地的机房作为灾难备份之用。而如果想最大程度地利用服务器的性能，我们还要求两地的数据中心能同时处理用户的请求。因此，在我们进行持续交付的过程中，就要考虑到双机房部署的问题了。
- 微服务架构
传统的单体应用和微服务架构的对比我相信很多同学都已经很熟悉了，所以我这里就不做过多的描述。API网关使用Spring Boot结合Spring Cloud的技术构建了基于微服务的分布式应用系统。API网关有包括授权验证服务，路由服务等在内的10多个微服务。这就要求在持续交付的过程中确保这些微服务都能够安全升级并且不能影响用户的使用。
- 优雅关闭与限流
在应用的发布过程中避免不了的就是对用户请求的限流和对应用服务的优雅关闭，达到对正在处理请求的0影响。
DevOps中的持续交付
- Infra as Code Ansible一键部署
由于发布的频繁和对发布正确性和可重复性的要求越来越高，我们对于部署的要求就是全面的自动化。我们对每一个服务的发布都有相应的Ansible自动发布脚本。脚本可以精确控制发布的顺序，使用蓝绿发布，使得用户能够在无感知的情况下升级应用程序。
- 开发运维统一团队
我们的研发团队主要在中国内地和香港，甚至有波兰的研发人员。高峰的时候我们全球有多大20人的研发团队成员，但是我们并没有一个专职的研发和运维人员，团队里面所有的开发人员都会参与代码的编写，测试和生产环境的部署。
- 自动化的功能回归测试
因为我们的目标在保证软件质量的前提下实施持续交付，所以必须施行全面自动化的功能性回归测试，确保在每次发布之前，我们已经有足够的信心不会影响现有的功能。同时，自动化的回归测试也能够很好地降低测试的人力成本，缩短测试的周期，避免人为的错误，提升团队的技能，让开发人员真正地投入到有意义的工作当中，而不是每次都施行重复性的体力劳动。这样，团队的开发人员也因此提高积极性。
- 自动化的性能测试
作为保证软件质量的一部分，我们在每次的生产环境升级之前，也必须实行性能测试，以确保新增的功能不会降低目前的软件性能。因为我们持续交付的原因，自动化的软件测试就必须施行，我们每次都会使用Jmeter对API网关的核心流程进行性能测试，对产出的性能测试报告和之前的报告对性对比分析，这样，我们就很容易得出这次的改动是否对现有的软件性能有所降低。
- Jenkins 自动化构建
为了标准化和尽量加速软件的构建流程，我们使用Jenkins对API网关的每一个微服务进行自动化的构建，构建的过程我们会使用指定的JDK进行编译，运行Junit单元测试，以确保所有的单元测试都通过才构建出符合质量的应用软件。为了保证软件的质量，我们要求单元测试的覆盖率起码需要在75%以上，而事实上，我们部分核心服务，例如，授权验证服务的单元测试覆盖率是高达90%以上的。
- Sonarqube质量检测
在自动化构建的过程里面，我们的其中一个步骤就是使用Sonarqube施行代码风格和质量的检测，我们要求发布的软件不可以存在Critial和Major的问题。针对其余的中低级别问题，我们会进行分析和标记，把有需要的进行整改，以确保代码的质量符合我们的预期。
- Checkmarx静态代码安全扫描
随着互联网安全话题的关注度越来越高，我们作为一家大型银行的网关系统，我们对代码的安全性的要求是极高的。在我们的构建过程里面，是会调用Checkmax进行代码的静态分析，检测是否存在安全漏洞。我们要求所有上线的应用程序都不可以存在Critial和Major的软件安全漏洞的。
- 全链路监控
在复杂的微服务架构系统中，几乎每一个API请求都会形成一个复杂的分布式服务调用链路。那么，在出现故障的时候，怎样定位出现问题的服务，如何检查调用过程中的性能问题呢？我们使用Zipkin对系统的全链路进行监控。
Zipkin
调用链跟踪分析
把同一TraceID的Span收集起来，按时间排序就是timeline。把ParentID串起来就是调用栈。
抛异常或者超时，在日志里打印TraceID。利用TraceID查询调用链情况，定位问题。
调用过程追踪
- 请求到来生成一个全局TraceID，通过TraceID可以串联起整个调用链，一个TraceID代表一次请求。
- 除了TraceID外，还需要SpanID用于记录调用父子关系。每个服务会记录下parent id和span id，通过他们可以组织一次完整调用链的父子关系。
- 一个没有parent id的span成为root span，可以看成调用链入口。 所有这些ID可用全局唯一的64位整数表示；
- 整个调用过程中每个请求都要透传TraceID和SpanID。
- 每个服务将该次请求附带的TraceID和附带的SpanID作为parent id记录下，并且将自己生成的SpanID也记录下。
- 要查看某次完整的调用则 只要根据TraceID查出所有调用记录，然后通过parent id和span id组织起整个调用父子关系。
Zipkin 架构图
下一步.........
Google Cloud Migration
原因
- 实现关系型数据库的异地双活，去Oracle
目前我们的服务是部署在集团的自建机房，后端也是采用Oracle关系型数据库。 每个数据中心我们会具备2个Oracle实例，使用VCS配置主从热备。不同的数据中心之间，我们采用DataGuard进行数据的同步。因此，基于现有的架构我们的数据库只是hot-warm的模式，并不能达到理想的live-live。
由于我们每年都会对应用服务进行数据中心间的切换测试，以确保备份的数据中心也能具备和主数据中心的同样的负载能力，并且可以在指定的时间内完成切换，所以我们经常经历数据库的切换工作。而且，当主数据库发生故障的时候，我们也要经历同样的切换工作。一来我们并不能在很短的时间内完成所有切换工作，二就是备份数据中心的数据也是有一定的延时的。
基于以上的原因，我们考虑使用Google Cloud的Cloud SQL或者Spanner进行关系型数据库的替换，实现关系型数据库的异地双活。降低数据库切换时的工作，同时保证数据在多机房间的同步。
- 服务器弹性伸缩
由于业务发展的需要，在未来的1到2年我们的网关可能迎来请求的暴增。所以服务器的弹性伸缩功能对我们来说就至关重要了。在现在的自建机房环境下，我们申请和配置一台生产环境的服务器是需要数个月甚至是上年的，而客户的请求可能在下一秒就回暴增，所以，我们必须找到这样的解决方案。
- 全面Infra as Code 定时重新构建服务器
为了配合服务器的弹性伸缩，我们的构建和部署代码也将会包括服务器的配置，例如JDK，环境变量等等，以达到我们可以使用脚本生成一台可用的服务器直接上线。
- 统一的Infra和应用监控
目前我们在工作中采取了多种的监控平台。
- 针对服务器我们有Plexus监控服务
- 针对分布式应用程日志我们会采用Splunk
- 针对服务的可能性监控，我们又采用了自建的BEATS监控服务
- 而服务器的告警服务我们就采用了xMatters。 简直就是五花百门。
因此，我希望能够采用一种统一的监控平台，对服务器和应用，告警等进行统一的配置，以简化工作和统一使用的环境。
