金融行业微服务架构解析

转载本文需注明出处:微信公众号EAWorld,违者必究。

引言:

对于微服务,每个人都有自己的理解,与互联网企业的大量落地相比,微服务在传统金融行业还没有普及,这首先是传统金融行业线上系统需求更新和版本迭代没有互联网公司那么频繁;其次是技术能力约束了新技术的落地;再者传统金融行业对系统可用性和稳定性的要求非常高。

如何理解微服务架构?微服务能够给金融行业带来什么?金融行业微服务架构如何选型?这些都需要我们对微服务架构进行深入的剖析。

目录:

一、什么是微服务

二、主流微服务框架

三、微服务架构关键技术一、什么是微服务?

微服务架构定义

微服务的定义源于 2014 年 3 月 Martin Fowler 所写的一篇文章“Microservices”,微服务的四个特性定义抽象为“小、独、轻、松”。

微服务的感性认识

转型之前:

紧耦合组件

慢的部署周期,等待集成测试

转型之后:

松耦合组件

自动化部署,无需等待独立组件

微服务优势

  1. 可伸缩性:服务的承载能力在设计之初并不能完全符合后来业务发展的要求,随着业务量增大,服务要通过服务器集群方式进行扩展,各个微服务的扩展数量也是按需求扩展,承载量大的微服务扩展节点多,承载量小的微服务扩展节点少,从而实现资源有效配置。
  2. 降低风险:准备好部署各个阶段的工件,包括:构建工件,测试脚本,配置文件和部署清单文件。a) 从负载均衡列表中移除掉“金丝雀”服务器。b) 升级“金丝雀”应用(排掉原有流量并进行部署)。c) 对应用进行自动化测试。d) 将“金丝雀”服务器重新添加到负载均衡列表中(连通性和健康检查)。e) 如果“金丝雀”在线使用测试成功,升级剩余的其他服务器。(否则就回滚)
  3. 弹性系统:在理想的设计中,一旦某一非核心微服务启动失败,其他微服务仍然可用,用户在没有使用到异常模块所提供的服务时,对这一异常完全无感知,大大增强了用户体验。
  4. 敏捷:开发成本降低,响应速度加快。各个开发团队的人员不必耗费大量时间了解整个服务端架构,主要通过了解某个微服务的金融业务需求和技术体系即可参与开发,从而降低了学习成本以及改动代码带来的风险,代码审查流程的简化也相应地加快了开发响应速度。
  5. 灵活:不要求所有的微服务都使用同一种技术和平台来实现。

微服务架构带来的问题

  1. 依赖服务变更很难跟踪,其他团队的服务接口文档过期怎么办?依赖的服务没有准备好,如何验证我开发的功能。
  2. 部分模块重复构建,跨团队、跨系统、跨语言会有很多的重复建设。
  3. 微服务放大了分布式架构的系列问题,如分布式事务怎么处理?依赖服务不稳定怎么办?
  4. 运维复杂度陡增,如:部署物数量多、监控进程多导致整体运维复杂度提升。

这些解决方案折腾到最后就会明白,原来我们要有一个微服务应用平台才能整体性的解决这些问题。

微服务架构适用场景

微服务架构并不是万能的,有它适合采用的系统,这些系统包括:

  1. 对于业务流程较为复杂,且业务会逐渐变得更加复杂的系统,单体应用将十分庞大,后期难以修改和维护,应考虑使用微服务架构。
  2. 为了满足业务需求,项目中引入了众多的技术栈,中间件,单体应用会给开发者带来很大的困扰,应考虑将应用拆分成多个独立部署的采用最优技术栈实施的微服务。
  3. 高并发的,有高可用和弹性伸缩需求的系统,往往是那些面向庞大数量互联网用户的平台类、交易类系统,应考虑利用微服务架构便于横向扩展和弹性伸缩的特性。
  4. 单体应用版本发布成本高,而单个微服务的变更和发布都很容易,那些有高频率版本发布需求的系统,应使用微服务架构。
  5. 没有数据实时强一致要求,可接受数据最终一致的系统,可使用微服务架构。

在银行系统中:

  1. OA、HR、绩效等管理类系统并不需要微服务架构;
  2. 信贷、CRM等管理类应用如果体积庞大(几十万行代码以上),要使用微服务改造;
  3. 中间业务、核心账务、网银由于系统压力大,可以采用微服务架构。

微服务架构在互联网金融方面的应用

  1. 第三方支付包括以支付宝、财付通、盛付通为代表的互联网支付企业,也包括快钱、汇付天下为代表的金融型支付企业。
  2. P2P小额信贷是一种个人对个人的直接信贷模式。
  3. 大数据金融是指集合海量非结构化数据,通过对其进行实时分析,可以为互联网金融机构提供客户全方位信息。
  4. 众筹融资指用团购+预购的形式,向网友募集项目资金的模式。众筹利用互联网传播的特性,让小企业、艺术家或个人对公众展示他们的创意,争取大家的关注和支持,进而获得所需要的资金援助。
  5. 所谓信息化金融机构,是指通过采用信息技术,对传统运营流程进行改造活重构,实现经营、管理全面电子化的银行、证券和保险等金融机构。
  6. 互联网金融门户是指利用互联网进行金融产品的销售以及为金融产品销售提供第三方服务的平台。它的核心就是“搜索+比价”的模式。

二、主流微服务框架

业界开源微服务框架方案比较

综合来看,SpringCloud是首选。为什么选择SpringCloud?

  1. 不只是解决微服务的某一个问题,而是一个解决微服务架构实施的综合性解决框架;
  2. 整合了诸多被广泛实践和证明过的框架作为实施的基础部件,又在该体系基础上创建了一些非常优秀的边缘组件 ;
  3. 大量的兼容性测试,保证了更好的稳定性;
  4. 极高的社区活跃度;

SpringCloud之于其他微服务框架就好比是:品牌机 VS  DIY电脑三、微服务架构关键技术

微服务平台技术图谱

微服务技术桟:

API Doc: Swagger UI

API Mock: Swagger Mock API

AOP基础框架:Spring framework

微服务容器:Spring Boot

服务发布:Spring Web MVC

服务注册中心:Spring Cloud – Eureka

服务路由:Spring Cloud – Ribbon

服务调用:Spring Cloud – Feign

服务熔断器:Spring Cloud – Hystrix

安全认证:Spring Cloud – Security

服务配置中心:Apollo , Spring Cloud – Config

服务监控:Spring Boot Admin

关键技术架构与设计

我们从这9个方面来解析微服务关键技术架构与设计。

1、前端UI框架

兼容性

Vue是流行的前端框架,其对浏览器的兼容性较好,主流的操作系统和浏览器都支持。

vue响应式双向数据绑定实现自动同步

vue.js采用数据劫持结合发布者-订阅者的方式,通过Object.defineProperty()来劫持各个属性的setter,getter,在数据变动时,发布消息给订阅者,触发相应的监听回调。

具体的来讲,Vue.js通过Directives指令去对DOM做封装,当数据发生变化,会通知指令去修改对应的DOM,数据驱动DOM的变化。vue.js还会对操作做一些监听(DOM Listener),当我们修改视图的时候,vue.js监听到这些变化,从而改变数据。这样就形成了数据的双向绑定。

2、微服务容器

微服务运行的容器环境

我们来看一下微服务运行容器,要做可靠高效的微服务架构应用,实际上我们需要做的事情还是非常多的。如果没有一个统一的微服务容器,这些能力在每个微服务组件中都需要建设一遍,而且会五花八门,也很难集成到一起。

微服务容器:负载均衡

微服务容器的基础服务能力之一就是支持负载均衡。

  1. 通常所说的负载均衡都指的是服务端负载均衡,其中分为硬件负载均衡和软件负载均衡。硬件负载均衡主要通过在服务器节点之间安装专门用于负载均衡的设备,比如F5等;而软件负载均衡则是通过在服务器上安装一些具有负载均衡功能或模块的软件来完成请求分发工作,比如Nigix等。
  2. 硬件负载均衡的设备或是软件负载均衡的软件模块都会维护一个下挂可用的服务端清单,通过心跳检测来剔除故障的服务端节点以保证清单中都是可以正常访问的服务端节点。当客户端发送请求到负载均衡设备时,该设备按照某种算法(比如线性轮询、按权重负载、按流量负载等)从维护的可用服务端清单中取出一台服务端的地址,然后进行转发。
  3. 客户端负载均衡和服务器负载均衡最大的不同点在于上面所提到的服务清单所存储的位置。在客户端负载均衡中,所有客户端节点都维护着自己要访问的服务端清单,而这些服务端的清单来自于服务注册中心,建议使用Spring Cloud Netflix 的Ribbon组件。

微服务容器:服务熔断、容错、升降级、限流

微服务容器的基础服务能力之二就是服务熔断、容错、升降级、限流,在系统出现异常时提供故障恢复能力。

3、注册中心

服务注册与发现

接下来我们聊一下注册发现,以前的单块应用之间互相调用时配置个IP就行了,但在微服务架构下,服务提供者会有很多,手工配置IP地址又变成了一个不可行的事情。那么服务自动注册发现的方案就解决了这个问题。

我们的服务注册发现能力是依赖SpringCloud Eureka组件实现的。服务在启动的时候,会将自己要发布的服务注册到服务注册中心,运行时,如果需要调用其他微服务的接口,那么就要先到注册中心获取服务提供者的地址,拿到地址后,通过微服务容器内部的简单负载均衡器进行路由。

一般情况,系统内微服务的调用都通过这种客户端负载均衡的模式进行,否则就需要有很多的负载均衡进程。跨业务系统的服务调用,也可以采用这种去中心化的路由方式。当然采用SOA的模式,由中心化的服务网管来管理系统间的调用也是另一种选择,要结合企业的IT现状和需求来决定。

4、配置中心

集中配置管理

微服务分布式环境下,一个系统拆分为很多个微服务,一定要告别投产或运维手工修改配置的方式。需要采用集中配置管理的方式来提升运维的效率。

配置文件主要有运行前的静态配置和运行期的动态配置两种。静态配置通常是在编译部署包之前设置好。动态配置则是系统运行过程中需要调整的系统变量或者业务参数。

要想做到集中的配置管理,那么需要注意以下几点:

  1. 配置与介质分离,这个就需要通过制定规范的方式来控制。千万别把配置放在Jar包里。
  2. 配置的方式要统一,格式、读写方式、变更热更新的模式尽量统一,要采用统一的配置框架
  3. 运行时需要有个配置中心来统一管理业务系统中的配置信息,这个就需要平台来提供配置中心服务和配置管理门户。

配置修改同步交互

配置修改后通过推送或者定时拉取的方式更新并缓存到应用程序所在的微服务容器中供应用程序使用。

高可用运行架构设计

配置中心有两种部署模式

  1. 高可用模式,见上图,支撑大规模微服务访问时根据负载情况可以对“配置查询同步服务”进行横向扩展
  2. ALL-IN-ONE模式,配置变更服务、配置查询服务合并为一个进程。适合支撑少量系统的场景使用。

配置中心可以支持高可用模式部署,满足金融行业的要求。

5、监控中心

基于Skywalking定制实现

SkyWalking主要就是通过收集各种格式的数据进行存储,然后展示。所以我们需要关注的是 SkyWalking Collecter、SkyWalking UI 和 存储设备。

APM探针

JavaAgent 是JDK 1.5 以后引入的,也可以叫做Java代理。

JavaAgent 是运行在 main方法之前的拦截器,它内定的方法名叫 premain ,也就是说先执行 premain 方法然后再执行 main 方法。

使用agent技术构建一个独立于应用程序的代理程序(即为Agent),用来协助监测、运行甚至替换其他JVM上的程序。使用它可以实现虚拟机级别的AOP功能。

APM全链路运行监控

调用链跟踪分析:把同一TraceID的Span收集起来,按时间排序就是timeline。把ParentID串起来就是调用栈。

实时分析:对单条日志直接分析,不做汇总,重组。得到当前QPS,延迟。

离线分析:按TraceID汇总,通过Span的ID和ParentID还原调用关系,分析链路形态。

6、日志中心

日志中心架构

日志分析是运维工程师解决系统故障,发现问题的主要手段。日志主要包括系统日志、应用程序日志和安全日志。系统运维和开发人员可以通过日志了解服务器软硬件信息、检查配置过程中的错误及错误发生的原因。经常分析日志可以了解服务器的负荷,性能安全性,从而及时采取措施纠正错误。

通常,日志被分散的储存在不同的设备上。如果你管理数十上百台服务器,你还在使用依次登录每台机器的传统方法查阅日志,即繁琐又效率低下。为此,我们使用集中化的日志管理,将所有服务器上的日志收集汇总。

集中化管理日志后,日志的统计和检索又成为一件比较麻烦的事情,这时实时日志分析ELK平台能够完美的解决上述的问题,ELK由ElasticSearch、Logstash和Kiabana三个开源工具组成。

规范日志与流水,问题追根溯源

作为一个微服务应用平台除了提供支撑开发和运行的技术组件和框架之外,还应该提供一些运维友好的经验总结,我们推荐的日志与流水实现如下:

  1. 先来看日志,平台应提供的日志主要有三种,系统日志,引擎日志还有跟踪日志。有了这些日志,在出问题的时候能够帮助我们获取一些关键信息进行问题定位。
  2. 要想做到出了问题能够追根溯源,那么右边的这些流水号的设计也是非常重要的,日志与各种流水号配合,能够让我们快速定位问题发生的具体时间地点以及相关信息,能够快速还原业务交易全链路。对这些日志与流水的细节处理,对于系统运维问题定位有非常大的帮助,没有这些有用的日志内容,ELK日志收集套件搭建的再漂亮,收一堆垃圾日志也是没用的。

通常开源框架只是提供个框架有开发人员自由发挥,而设计一个平台则一定要考虑直接提供统一规范的基础能力。

7、API Gateway

基于Spring Cloud Netflix的Zuul组件定制实现

异步非阻塞模式启动的线程很少,基本上一个CPU core上只需启一个处理线程,它使用的线程资源就很少,上下文切换(Context Switch)开销也少。非阻塞模式可以接受的连接数大大增加,可以简单理解为请求来了只需要进队列,这个队列的容量可以设得很大,只要不超时,队列中的请求都会被依次处理。

API Gateway逻辑架构

API网关就像整个系统的门面一样,所有的外部访问都经过它实现调度、过滤、请求路由、负载均衡、校验等等。

API Gateway 功能

API网关上还可以实现更多更复杂的功能。

8、IAM(Identity and Access Management)

IAM架构

IAM为企业提供统一的账号管理视角,对所有基于账号的管理、认证、授权、审计进行集中的统一管理,提高了账号管理的安全,帮助系统管理员提高了工作效率,降低了管理负担,同时改善了普通用户在不同资源中登录认证的重复繁琐过程,为日常工作提供了更高的安全性。

统一用户中心

IAM可以为企业所有的资源使用人员如普通用户、系统管理人员、驻场代维人员、合作伙伴、临时工作人员等定义主账号,按照公司的组织方式对人员进行管理。通过一对一的主账号管理模式,可以在该平台实现对所有资源使用人员进行集中定义、集中维护等生命周期管理。

统一认证与鉴权

安全认证方面,我们基于Spring Security结合Auth2再加上JWT(Json web token)做安全令牌,实现统一的安全认证与鉴权,使得微服务之间能够按需隔离和安全互通。认证鉴权一定是个公共的服务,而不是多个系统各自建设。

9、微服务管理

服务管理机制

  • 服务提供者:
  1. 服务注册在服务注册时,需要确认下eureka.client.register-with-eureka=true参数是否正确,默认为true,若设置为false将不会启动注册操作。
  2. 服务同步由于服务注册中心之间因互相注册为服务,当服务提供者发送注册请求到一个服务注册中心,它会将该请求转发给集群中相连的其他注册中心,从而实现注册中心之间的服务同步。
  3. 服务续约eureka.instance.lease-renewal-interval-in-seconds参数用于定义服务续约任务的调用间隔时间默认30秒。eureka.instance.lease-exptration-duration-in-seconds参数用于定义服务失效时间,默认为90秒。
  • 服务消费者:
  1. 获取服务当我们启动服务消费者时候,它会发送一个REST请求给服务注册中心,来获取上面注册的服务清单。为了性能考虑,Eureka Server会维护一份只读的服务清单来返回给客户端,同时该缓存清单会每隔30秒更新一次。
  2. 服务调用服务消费者在获取服务清单后,通过服务名可以获得具体提供服务的实例名和该实例的元数据。因为有这些服务实例的详细信息,所以客户端可以根据自己的需要决定具体调用哪个实例。

单服务异常导致雪崩

采用微服务架构后,服务之间会有错综复杂的依赖关系,例如,一个前端请求一般会依赖于多个后端服务。

在微服务架构中,存在着那么多的服务单元,若一个单元出现故障,就很容易因依赖关系而引发故障的蔓延,最终导致整个系统的瘫痪,造成所谓的雪崩效应,这样的架构较传统架构更加不稳定。

自我保护

当网络分区故障发生时,微服务与Eureka Server之间无法正常通信,而微服务本身是正常运行的,此时不应该移除这个微服务,所以引入了自我保护机制。

服务注册到Eureka Server之后,会维护一个心跳连接,告诉Eureka Server自己还活着。Eureka Server在运行期间,会统计心跳失败的比例在15分钟之内是否低于85%,如果出现低于的情况,Eureka Server会将当前的实例注册信息保护起来,让这些实例不会过期,尽可能保护这些注册信息。

服务容错处理

  1. 资源隔离:包括线程池隔离和信号量隔离,限制调用分布式服务的资源使用,某一个调用的服务出现问题不会影响其他服务调用
  2. 降级机制:超时降级、资源不足时(线程或信号量)降级,降级后可以配合降级接口返回托底数据。
  3. 熔断:当失败率达到阀值自动触发降级(如因网络故障/超时造成的失败率高),熔断器触发的快速失败会进行快速恢复。
  4. 缓存:提供了请求缓存、请求合并实现。

精选提问:

问1:服务下线之后,eureka默认有30秒的心跳,怎么做到优雅下线呢?

答:spring-boot-starter-actuator中提供了/shutdown的方式优雅下线。

问2:微服务中事物的一致性怎么保证?

答:事务一致性保证:可靠事件模式、补偿模式、TCC。

问3:hystrix不更新了,有别的替换组件吗?

答:hystrix不更新,可以选择Resilience4j和Sentinel。

问4:服务提供者a 往eureka注册了服务,不希望 B 能看到这个服务。能做到吗?

答:应用注册到Eureka可以进行分组,服务消费端可以指定访问目标应用的其中一个组内的实例。

问5:IAM的授权是全局的还是只是账户管理系统的,全局的怎么实现资源和资源组的统一管理?

答:IAM提供统一账户管理,授权对企业来说是全局的。资源指的是应用功能权限的话,可以集中管理或者应用自治,按需选择。

问6:微服务是否适合高并发实时数据的处理?

答:微服务是一种架构风格,具体里面的应用可以是实时交易类、数据分析类,并没有限制。

问7:微服务与大数据、分布式的关系,微服务对环境的要求是什么,单机是否可以部署微服务?

答:微服务是一种架构风格,通常采用分布式部署。如果是做demo部署到单机没问题。

问8:hystrix或sentinel能否做到对应用集群整体的流控/熔断控制啊?

答:整体的熔断一般手工做。比如通过负载均衡下线。流控hystrix貌似不管。建议流控在网关上做。

Image placeholder
IT头条
未设置
  79人点赞

没有讨论,发表一下自己的看法吧

推荐文章
海量数据时代,金融行业数据库实践难题如何解决?

随着数字经济时代的到来,大数据、人工智能技术得到了快速发展与应用,可以说,各行各业都已全情投入到这一波数字化转型浪潮中,把握新的发展机遇,获取数字红利。其中,金融行业可以说是走在转型之路最前沿的行业之

SOA架构和微服务架构的区别是什么?

来源:rrd.me/fqdANSOA架构和微服务架构的区别首先SOA和微服务架构一个层面的东西,而对于ESB和微服务网关是一个层面的东西,一个谈到是架构风格和方法,一个谈的是实现工具或组件。1.SOA

Spring Cloud 上手实战-架构解析及实作

Spring简介为什么要使用微服务单体应用:目前为止绝大部分的web应用软件采用单体应用,所有的应用的用户UI、业务逻辑、数据库访问都打包在一个应用程序上。缺点:开发相互干扰,随着应用的不断升级沟通协

微服务架构之「 服务注册 」

微服务架构是一个庞大复杂的工程,为什么说它庞大复杂呢?因为想要做好微服务,就必须先要建设好微服务所需的一系列基础设施和组件。我在前面的文章《架构设计之「微服务入门」》中已经初步介绍过了这些组件,包括:

微服务架构中如何构建一个数据报告服务?

场景描述在微服务架构中,每个微服务负责自己的数据库,微服务A是不允许直接连接微服务B的数据库进行操作的。现在有2个微服务,一个是订单服务,一个是用户服务。有一个数据报告的需求:生成一份包含用户信息的订

微服务架构:拆分单体应用的难点

拆分单体应用为服务的难点从表面上看,通过定义与业务能力或子域相对应的服务来创建微服务架构的策略看起来很简单。但是,你可能会遇到几个障碍:网络延迟。同步进程间通信导致可用性降低。 在服务之间维持数据一致

微服务架构的四大金刚利器

Photo@ChristopherCampbell 文 | 孔凡勇概述互联网应用发展到今天,从单体应用架构到SOA以及今天的微服务,随着微服务化的不断升级进化,服务和服务之间的稳定性变得越来越重要,分

一个知名网站的微服务架构最佳实现

译者:蓝梦,十余年研发经验,现就职于某上市互联网公司。作者:小马,Medium 首席架构师。译者有话说,如果你的项目正在从单体升级为微服务而忧心;或者你在实践微服务过程中手忙脚乱,本文都是你不容错过的

微服务架构的四大杀手锏

Photo@ChristopherCampbell 文 | 孔凡勇概述互联网应用发展到今天,从单体应用架构到SOA以及今天的微服务,随着微服务化的不断升级进化,服务和服务之间的稳定性变得越来越重要,分

工商银行MySQL数据库架构解密

本文根据DTCC数据库大会分享内容整理而成,将介绍工行IT架构转型中传统OLTP数据库架构面临的挑战和诉求,构建基于MySQL分布式企业级解决方案实践历程,包括技术选择、高可用设计、两地三中心容灾、运

架构转型先行——金融业务场景下的新一代架构实践

  赵勇中国农业银行研发中心架构管理办公室主任工程师中国农业银行研发中心架构管理办公室主任工程师,十年以上金融行业信息化架构设计与管控经验。历经互联网金融、两地三中心、分布式核心银行等大型银行系统工程

重兵投入行业市场,新华三开启信息安全行业元年

4月19日-20日,为期两天的2019领航者峰会在重庆举行,本届峰会主题为“数字领航·智绘未来”。通过本届大会,新华三都向大家传达了哪些信息?关于信息安全新华三又有着哪些新的动作?在数字化时代,一个企

包银消费CTO汤向军:消费金融大数据风控架构与实践

01风险在哪里1.1 信用风险根据银行业的风险理论,信用风险是指借款人因各种原因未能及时、足额偿还债权人或银行贷款而违约的可能性。信用风险的风控重点在于,甄别客户违约的原因究竟是还款能力,还是还款意愿

当金融科技遇上云原生,蚂蚁金服是怎么做安全架构的?

蚂蚁金服在过去十五年重塑支付改变生活,为全球超过十二亿人提供服务,这些背后离不开技术的支撑。在2019杭州云栖大会上,蚂蚁金服将十五年来的技术沉淀,以及面向未来的金融技术创新和参会者分享。我们将其中的

大神讲解微服务治理的技术演进和架构实践

摘要:随着业务的发展,规模扩大,服务越来越多,需要协调线上运行的各个服务,保障服务的SLA;基于服务调用的性能KPI数据进行容量管理,合理分配各服务的资源占用;对故障业务做服务降级、流量控制、流量迁移

清晰架构(Clean Architecture)的Go微服务: 日志管理

良好的日志记录可以提供丰富的日志数据,便于在调试时发现问题,从而大大提高编码效率。记录器提供的自动化信息越多越好,日志信息也需要以简洁的方式呈现,便于找到重要的数据。日志需求: 无需修改业务代码即可切

一站式入口服务|爱奇艺微服务平台 API 网关实战

写在前面在互联网业务微服务化改造过程中,按照以往的服务治理体系,各服务需要单独实现限流、鉴权、监控、日志等通用功能,构建入口时资源申请、工单批复、多系统配置等一系列流程对精力消耗极大,学习成本较高

号称以客户为中心的保险行业如何做到真正的“按需”服务?

随着客户消费模式的改变和对服务要求的不断提高,当前保险行业正经历深刻变化。虽然保险行业已经积累了大量的客户数据,但由于其业务的复杂性及缺少系统的建设,大多数数据都是孤立的。而在数字化浪潮的推进下,许多

哪些行业需要使用高防服务器?

如今,随着互联网的普及,企业的业务开展离不开服务器,特别是针对热门互联网行业,如游戏、金融、电商、直播等领域,推荐使用高防服务器。因为这几个行业竞争非常激烈,容易遭到同行恶意攻击报复、敲诈勒索,是DD

万字详解Oracle架构、原理、进程,学会世间再无复杂架构

学习是一个循序渐进的过程,从面到点、从宏观到微观,逐步渗透,各个击破,对于Oracle, 怎么样从宏观上来理解呢?先来看一个图,这个图取自于教材,这个图对于从整体上理解ORACLE 的体系结构组件,非

数字转型 架构演进 2019中国系统架构师大会盛大召开

2019年10月31日~11月2日,由IT168旗下ChinaUnix社区主办的第十一届中国系统架构师大会(SACC2019)在北京隆重召开。自2009年举办以来,大会云集了国内CTO、研发总监、高级

阿里支付宝架构师:谈谈我眼中的高并发架构【好文】

来源:my.oschina.net/u/3772106/blog/1793561前言高并发经常会发生在有大活跃用户量,用户高聚集的业务场景中,如:秒杀活动,定时领取红包等。为了让业务可以流畅的运行并且

架构师眼中的高并发架构

前言高并发经常发生在有大活跃用户量和用户高聚集的业务场景中,如:秒杀活动、定时领取红包等。为了让业务可以流畅的运行并且给用户一个好的交互体验,我们需要根据业务场景预估达到的并发量等因素,来设计适合自己

云计算下半场,从金融业变革看云原生的机遇与挑战

在数字化转型过程中,上云上平台是非常关键的一步。如今是否上云已经不需讨论,云计算在国内经过十年的发展走到了下半场,成为传统产业升级的新助力。而伴随着容器、微服务等技术的逐步成熟,云计算也走到了云原生时

区块链仍处于婴儿期,金融业是应用最多的两个领域之一

如果问你2018年什么技术比较火,答案中一定会有区块链。从春节“3点钟无眠区块链”的狂欢开始,伴随着过山车一般的币价逐渐走向沉寂,链圈、矿圈、币圈的鄙视链似乎也不再那么重要。10月24日下午过后,在国