首页
题库
公司真题
专项练习
面试题库
在线编程
面试
面试经验
AI 模拟面试
简历
求职
课程
基础学习课
实战项目课
求职辅导课
专栏&文章
竞赛
搜索
我要招人
发布职位
发布职位、邀约牛人
更多企业解决方案
在线笔面试、雇主品牌宣传
登录
/
注册
牛客147625346号
计算机类
发布于北京
关注
已关注
取消关注
@程序员大彬:
微服务高频面试题
什么是微服务?微服务是将一个原本独立的系统拆分成多个小型服务,这些小型服务都在各自独立的进程中运行,服务和服务之间采用轻量级的通信机制进行协作。每个服务可以被独立的部署到生产环境。从单体应用到微服务单体系统的缺点:修改一个小功能,就需要将整个系统重新部署上线,影响其他功能的运行;功能模块互相依赖,强耦合,扩展困难。如果出现性能瓶颈,需要对整体应用进行升级,虽然影响性能的可能只是其中一个小模块;单体系统的优点:容易部署,程序单一,不存在分布式集群的复杂部署环境;容易测试,没有复杂的服务调用关系。微服务的优点:不同的服务可以使用不同的技术;隔离性。一个服务不可用不会导致其他服务不可用;可扩展性。某个服务出现性能瓶颈,只需对此服务进行升级即可;简化部署。服务的部署是独立的,哪个服务出现问题,只需对此服务进行修改重新部署;微服务的缺点:网络调用频繁。性能相对函数调用较差。运维成本增加。系统由多个独立运行的微服务构成,需要设计一个良好的监控系统对各个微服务的运行状态进行监控。分布式和微服务的区别从概念理解,分布式服务架构强调的是服务化以及服务的分散化,微服务则更强调服务的专业化和精细分工;从实践的角度来看,微服务架构通常是分布式服务架构,反之则未必成立。一句话概括:分布式:分散部署;微服务:分散能力。服务怎么划分?横向拆分:按照不同的业务域进行拆分,例如订单、营销、风控、积分资源等。形成独立的业务领域微服务集群。纵向拆分:把一个业务功能里的不同模块或者组件进行拆分。例如把公共组件拆分成独立的原子服务,下沉到底层,形成相对独立的原子服务层。这样一纵一横,就可以实现业务的服务化拆分。要做好微服务的分层:梳理和抽取核心应用、公共应用,作为独立的服务下沉到核心和公共能力层,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求总之,微服务的设计一定要 渐进式 的,总的原则是 服务内部高内聚,服务之间低耦合。微服务设计原则单一职责原则意思是每个微服务只需要实现自己的业务逻辑就可以了,比如订单管理模块,它只需要处理订单的业务逻辑就可以了,其它的不必考虑。服务自治原则意思是每个微服务从开发、测试、运维等都是独立的,包括存储的数据库也都是独立的,自己就有一套完整的流程,我们完全可以把它当成一个项目来对待。不必依赖于其它模块。轻量级通信原则首先是通信的语言非常的轻量,第二,该通信方式需要是跨语言、跨平台的,之所以要跨平台、跨语言就是为了让每个微服务都有足够的独立性,可以不受技术的钳制。接口明确原则由于微服务之间可能存在着调用关系,为了尽量避免以后由于某个微服务的接口变化而导致其它微服务都做调整,在设计之初就要考虑到所有情况,让接口尽量做的更通用,更灵活,从而尽量避免其它模块也做调整。微服务之间是如何通讯的?1、RPC远程过程调用,简单的理解是一个节点请求另一个节点提供的服务。优点:简单,常见。因为没有中间件代理,系统更简单缺点:只支持请求/响应的模式,不支持别的,比如通知、发布/订阅降低了可用性,因为客户端和服务端在请求过程中必须都是可用的2、消息队列除了标准的基于RPC通信的微服务架构,还有基于消息队列通信的微服务架构,这种架构下的微服务采用发送消息(Publish Message)与监听消息(Subscribe Message)的方式来实现彼此之间的交互。网易的蜂巢平台就采用了基于消息队列的微服务架构设计思路,如下图所示,微服务之间通过RabbitMQ传递消息,实现通信。与上面几种微服务架构相比,基于消息队列的微服务架构并不多,案例也相对较少,更多地体现为一种与业务相关的设计经验,各家有各家的实现方式,缺乏公认的设计思路与参考架构,也没有形成一个知名的开源平台。因此,如果需要实施这种微服务架构,则基本上需要项目组自己从零开始去设计实现一个微服务架构基础平台,其代价是成本高、风险大。优点:把客户端和服务端解耦,更松耦合提高可用性,因为消息中间件缓存了消息,直到消费者可以消费支持很多通信机制比如通知、发布/订阅等缺点:缺乏公认的设计思路与参考架构,也没有形成一个知名的开源平台成本高、风险大熔断器雪崩效应:假如存在这样的调用链路,a服务->b服务->c服务,当c服务挂了的时候,b服务调用c服务会等待超时,a服务调用b服务也会等待超时,调用方长时间等不到相应而占用线程,如果有大量的请求过来,就会造成线程池打满,导致整个链路的服务奔溃。为了解决分布式系统的雪崩效应,分布式系统引进了熔断器机制 。当一个服务的处理用户请求的失败次数在一定时间内小于设定的阀值时,熔断器出于关闭状态,服务正常。当服务处理用户请求失败次数在一定时间内大于设定的阀值时,说明服务出现故障,打开熔断器,这时所有的请求会快速返回失败的错误信息,不执行业务逻辑,从而防止故障的蔓延。当处于打开状态的熔断器时,一段时间后出于半打开状态,并执行一定数量的请求,剩余的请求会执行快速失败,若执行请求失败了,则继续打开熔断器,若成功了,则将熔断器关闭。服务网关何为网关?通俗一点的讲:网关就是要去别的网络的时候,把报文首先发送到的那台设备。稍微专业一点的术语,网关就是当前主机的默认路由。网关一般就是一台路由器,有点像“一个小区中的一个邮局”,小区里面的住户互相是知道怎么走,但是要向外地投递东西就不知道了,怎么办?把地址写好送到本小区的邮局就好了。那么,怎么区分是“本小区”和“外地小区”的呢?根据IP地址 + 掩码。如果是在一个范围内的,就是本小区(局域网内部),如果掩不住的,就是外地的。例如,你的机器的IP地址是:192.168.0.2/24,网关是192.168.0.1如果机器访问的IP地址范围是:192.168.0.1~192.168.0.254的,说明是一个小区的邻居,你的机器就直接发送了(和网关没任何关系)。如果你访问的IP地址不是这个范围的,则就投递到192.168.0.1上,让这台设备来转发。参考:https://www.zhihu.com/question/362842680/answer/951412213何为API网关假设你正在开发一个电商网站,那么这里会涉及到很多后端的微服务,比如会员、商品、推荐服务等等。那么这里就会遇到一个问题,APP/Browser怎么去访问这些后端的服务? 如果业务比较简单的话,可以给每个业务都分配一个独立的域名(https://service.api.company.com),但这种方式会有几个问题:每个业务都会需要鉴权、限流、权限校验等逻辑,如果每个业务都各自为战,自己造轮子实现一遍,会很蛋疼,完全可以抽出来,放到一个统一的地方去做。如果业务量比较简单的话,这种方式前期不会有什么问题,但随着业务越来越复杂,比如淘宝、亚马逊打开一个页面可能会涉及到数百个微服务协同工作,如果每一个微服务都分配一个域名的话,一方面客户端代码会很难维护,涉及到数百个域名每上线一个新的服务,都需要运维参与,申请域名、配置Nginx等,当上线、下线服务器时,同样也需要运维参与,另外采用域名这种方式,对于环境的隔离也不太友好,调用者需要自己根据域名自己进行判断。另外还有一个问题,后端每个微服务可能采用了不同的协议,比如HTTP、AMQP、自定义TCP协议等,但是你不可能要求客户端去适配这么多种协议,这是一项非常有挑战的工作,项目会变的非常复杂且很难维护。更好的方式是采用API网关(也叫做服务网关),实现一个API网关接管所有的入口流量,类似Nginx的作用,将所有用户的请求转发给后端的服务器,但网关做的不仅仅只是简单的转发,也会针对流量做一些扩展,比如鉴权、限流、权限、熔断、协议转换、错误码统一、缓存、日志、监控、告警等,这样将通用的逻辑抽出来,由网关统一去做,业务方也能够更专注于业务逻辑,提升迭代的效率。通过引入API网关,客户端只需要与API网关交互,而不用与各个业务方的接口分别通讯,但多引入一个组件就多引入了一个潜在的故障点,因此要实现一个高性能、稳定的网关,也会涉及到很多点。网关层通常以集群的形式存在。并在服务网关层前通常会加上Nginx 用来负载均衡。服务网关基本功能:智能路由:接收外部一切请求,并转发到后端的对外服务。注意:我们只转发外部请求,服务之间的请求不走网关,这就表示全链路追踪、内部服务API监控、内部服务之间调用的容错、智能路由不能在网关完成;当然,也可以将所有的服务调用都走网关,那么几乎所有的功能都可以集成到网关中,但是这样的话,网关的压力会很大,不堪重负。权限校验:网关可以做一些用户身份认证,权限认证,防止非法请求操作API 接口,对内部服务起到保护作用API监控:监控经过网关的请求,以及网关本身的一些性能指标(gc等)限流:与监控配合,进行限流操作API日志统一收集:类似于一个aspect切面,记录接口的进入和出去时的相关日志当然,网关实现这些功能,需要做高可用,否则网关很可能成为架构的瓶颈,最常用的网关组件Zuul、Nginx服务配置统一管理在微服务架构中,需要有统一管理配置文件的组件,例如:SpringCloud Config组件、阿里的Diamond、百度的Disconf、携程的Apollo等服务链路追踪在微服务架构中,必须实现分布式链路追踪,去跟进一个请求到底有哪些服务参与、参与顺序,是每个请求链路清晰可见,便于问题快速定位。常用链路追踪组件有Google的Dapper、Twitter 的Zipkin,以及阿里Eagleeye。微服务框架市面常用微服务框架有:Spring Cloud 、Dubbo 、kubernetes从功能模块上考虑,Dubbo缺少很多功能模块,例如网关、链路追踪等从学习成本上考虑,Dubbo 版本趋于稳定,稳定完善、可以即学即用,难度简单,Spring cloud 基于Spring Boot,需要先掌握Spring Boot ,例外Spring cloud 大多为英文文档,要求学习者有一定的英文阅读能力从开发风格考虑,Dubbo倾向于xml的配置方式,Spring cloud 基于Spring Boot ,采用基于注解和JavaBean配置方式的敏捷开发从开发速度上考虑,Spring cloud 具有更高的开发和部署速度从通信方式上考虑,Spring cloud 基于HTTP Restful 风格,服务于服务之间完全无关、无耦合。Dubbo 基于远程调用,对接口、平台和语言有强依赖性,如果需要实现跨平台,需要有额外的中间件。所以Dubbo专注于服务治理;Spring Cloud关注于微服务架构生态。微服务是将一个原本独立的系统拆分成多个小型服务,这些小型服务都在各自独立的进程中运行,服务和服务之间采用轻量级的通信机制进行协作。每个服务可以被独立的部署到生产环境。从单体应用到微服务单体系统的缺点:修改一个小功能,就需要将整个系统重新部署上线,影响其他功能的运行;功能模块互相依赖,强耦合,扩展困难。如果出现性能瓶颈,需要对整体应用进行升级,虽然影响性能的可能只是其中一个小模块;单体系统的优点:容易部署,程序单一,不存在分布式集群的复杂部署环境;容易测试,没有复杂的服务调用关系。微服务的优点:不同的服务可以使用不同的技术;隔离性。一个服务不可用不会导致其他服务不可用;可扩展性。某个服务出现性能瓶颈,只需对此服务进行升级即可;简化部署。服务的部署是独立的,哪个服务出现问题,只需对此服务进行修改重新部署;微服务的缺点:网络调用频繁。性能相对函数调用较差。运维成本增加。系统由多个独立运行的微服务构成,需要设计一个良好的监控系统对各个微服务的运行状态进行监控。分布式和微服务的区别从概念理解,分布式服务架构强调的是服务化以及服务的分散化,微服务则更强调服务的专业化和精细分工;从实践的角度来看,微服务架构通常是分布式服务架构,反之则未必成立。一句话概括:分布式:分散部署;微服务:分散能力。服务怎么划分?横向拆分:按照不同的业务域进行拆分,例如订单、营销、风控、积分资源等。形成独立的业务领域微服务集群。纵向拆分:把一个业务功能里的不同模块或者组件进行拆分。例如把公共组件拆分成独立的原子服务,下沉到底层,形成相对独立的原子服务层。这样一纵一横,就可以实现业务的服务化拆分。要做好微服务的分层:梳理和抽取核心应用、公共应用,作为独立的服务下沉到核心和公共能力层,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求总之,微服务的设计一定要 渐进式 的,总的原则是 服务内部高内聚,服务之间低耦合。微服务设计原则单一职责原则意思是每个微服务只需要实现自己的业务逻辑就可以了,比如订单管理模块,它只需要处理订单的业务逻辑就可以了,其它的不必考虑。服务自治原则意思是每个微服务从开发、测试、运维等都是独立的,包括存储的数据库也都是独立的,自己就有一套完整的流程,我们完全可以把它当成一个项目来对待。不必依赖于其它模块。轻量级通信原则首先是通信的语言非常的轻量,第二,该通信方式需要是跨语言、跨平台的,之所以要跨平台、跨语言就是为了让每个微服务都有足够的独立性,可以不受技术的钳制。接口明确原则由于微服务之间可能存在着调用关系,为了尽量避免以后由于某个微服务的接口变化而导致其它微服务都做调整,在设计之初就要考虑到所有情况,让接口尽量做的更通用,更灵活,从而尽量避免其它模块也做调整。微服务之间是如何通讯的?1、RPC远程过程调用,简单的理解是一个节点请求另一个节点提供的服务。优点:简单,常见。因为没有中间件代理,系统更简单缺点:只支持请求/响应的模式,不支持别的,比如通知、发布/订阅降低了可用性,因为客户端和服务端在请求过程中必须都是可用的2、消息队列除了标准的基于RPC通信的微服务架构,还有基于消息队列通信的微服务架构,这种架构下的微服务采用发送消息(Publish Message)与监听消息(Subscribe Message)的方式来实现彼此之间的交互。网易的蜂巢平台就采用了基于消息队列的微服务架构设计思路,如下图所示,微服务之间通过RabbitMQ传递消息,实现通信。与上面几种微服务架构相比,基于消息队列的微服务架构并不多,案例也相对较少,更多地体现为一种与业务相关的设计经验,各家有各家的实现方式,缺乏公认的设计思路与参考架构,也没有形成一个知名的开源平台。因此,如果需要实施这种微服务架构,则基本上需要项目组自己从零开始去设计实现一个微服务架构基础平台,其代价是成本高、风险大。优点:把客户端和服务端解耦,更松耦合提高可用性,因为消息中间件缓存了消息,直到消费者可以消费支持很多通信机制比如通知、发布/订阅等缺点:缺乏公认的设计思路与参考架构,也没有形成一个知名的开源平台成本高、风险大熔断器雪崩效应:假如存在这样的调用链路,a服务->b服务->c服务,当c服务挂了的时候,b服务调用c服务会等待超时,a服务调用b服务也会等待超时,调用方长时间等不到相应而占用线程,如果有大量的请求过来,就会造成线程池打满,导致整个链路的服务奔溃。为了解决分布式系统的雪崩效应,分布式系统引进了熔断器机制 。当一个服务的处理用户请求的失败次数在一定时间内小于设定的阀值时,熔断器出于关闭状态,服务正常。当服务处理用户请求失败次数在一定时间内大于设定的阀值时,说明服务出现故障,打开熔断器,这时所有的请求会快速返回失败的错误信息,不执行业务逻辑,从而防止故障的蔓延。当处于打开状态的熔断器时,一段时间后出于半打开状态,并执行一定数量的请求,剩余的请求会执行快速失败,若执行请求失败了,则继续打开熔断器,若成功了,则将熔断器关闭。服务网关何为网关?通俗一点的讲:网关就是要去别的网络的时候,把报文首先发送到的那台设备。稍微专业一点的术语,网关就是当前主机的默认路由。网关一般就是一台路由器,有点像“一个小区中的一个邮局”,小区里面的住户互相是知道怎么走,但是要向外地投递东西就不知道了,怎么办?把地址写好送到本小区的邮局就好了。那么,怎么区分是“本小区”和“外地小区”的呢?根据IP地址 + 掩码。如果是在一个范围内的,就是本小区(局域网内部),如果掩不住的,就是外地的。例如,你的机器的IP地址是:192.168.0.2/24,网关是192.168.0.1如果机器访问的IP地址范围是:192.168.0.1~192.168.0.254的,说明是一个小区的邻居,你的机器就直接发送了(和网关没任何关系)。如果你访问的IP地址不是这个范围的,则就投递到192.168.0.1上,让这台设备来转发。参考:https://www.zhihu.com/question/362842680/answer/951412213何为API网关假设你正在开发一个电商网站,那么这里会涉及到很多后端的微服务,比如会员、商品、推荐服务等等。那么这里就会遇到一个问题,APP/Browser怎么去访问这些后端的服务? 如果业务比较简单的话,可以给每个业务都分配一个独立的域名(https://service.api.company.com),但这种方式会有几个问题:每个业务都会需要鉴权、限流、权限校验等逻辑,如果每个业务都各自为战,自己造轮子实现一遍,会很蛋疼,完全可以抽出来,放到一个统一的地方去做。如果业务量比较简单的话,这种方式前期不会有什么问题,但随着业务越来越复杂,比如淘宝、亚马逊打开一个页面可能会涉及到数百个微服务协同工作,如果每一个微服务都分配一个域名的话,一方面客户端代码会很难维护,涉及到数百个域名每上线一个新的服务,都需要运维参与,申请域名、配置Nginx等,当上线、下线服务器时,同样也需要运维参与,另外采用域名这种方式,对于环境的隔离也不太友好,调用者需要自己根据域名自己进行判断。另外还有一个问题,后端每个微服务可能采用了不同的协议,比如HTTP、AMQP、自定义TCP协议等,但是你不可能要求客户端去适配这么多种协议,这是一项非常有挑战的工作,项目会变的非常复杂且很难维护。更好的方式是采用API网关(也叫做服务网关),实现一个API网关接管所有的入口流量,类似Nginx的作用,将所有用户的请求转发给后端的服务器,但网关做的不仅仅只是简单的转发,也会针对流量做一些扩展,比如鉴权、限流、权限、熔断、协议转换、错误码统一、缓存、日志、监控、告警等,这样将通用的逻辑抽出来,由网关统一去做,业务方也能够更专注于业务逻辑,提升迭代的效率。通过引入API网关,客户端只需要与API网关交互,而不用与各个业务方的接口分别通讯,但多引入一个组件就多引入了一个潜在的故障点,因此要实现一个高性能、稳定的网关,也会涉及到很多点。网关层通常以集群的形式存在。并在服务网关层前通常会加上Nginx 用来负载均衡。服务网关基本功能:智能路由:接收外部一切请求,并转发到后端的对外服务。注意:我们只转发外部请求,服务之间的请求不走网关,这就表示全链路追踪、内部服务API监控、内部服务之间调用的容错、智能路由不能在网关完成;当然,也可以将所有的服务调用都走网关,那么几乎所有的功能都可以集成到网关中,但是这样的话,网关的压力会很大,不堪重负。权限校验:网关可以做一些用户身份认证,权限认证,防止非法请求操作API 接口,对内部服务起到保护作用API监控:监控经过网关的请求,以及网关本身的一些性能指标(gc等)限流:与监控配合,进行限流操作API日志统一收集:类似于一个aspect切面,记录接口的进入和出去时的相关日志当然,网关实现这些功能,需要做高可用,否则网关很可能成为架构的瓶颈,最常用的网关组件Zuul、Nginx服务配置统一管理在微服务架构中,需要有统一管理配置文件的组件,例如:SpringCloud Config组件、阿里的Diamond、百度的Disconf、携程的Apollo等服务链路追踪在微服务架构中,必须实现分布式链路追踪,去跟进一个请求到底有哪些服务参与、参与顺序,是每个请求链路清晰可见,便于问题快速定位。常用链路追踪组件有Google的Dapper、Twitter 的Zipkin,以及阿里Eagleeye。微服务框架市面常用微服务框架有:Spring Cloud 、Dubbo 、kubernetes从功能模块上考虑,Dubbo缺少很多功能模块,例如网关、链路追踪等从学习成本上考虑,Dubbo 版本趋于稳定,稳定完善、可以即学即用,难度简单,Spring cloud 基于Spring Boot,需要先掌握Spring Boot ,例外Spring cloud 大多为英文文档,要求学习者有一定的英文阅读能力从开发风格考虑,Dubbo倾向于xml的配置方式,Spring cloud 基于Spring Boot ,采用基于注解和JavaBean配置方式的敏捷开发从开发速度上考虑,Spring cloud 具有更高的开发和部署速度从通信方式上考虑,Spring cloud 基于HTTP Restful 风格,服务于服务之间完全无关、无耦合。Dubbo 基于远程调用,对接口、平台和语言有强依赖性,如果需要实现跨平台,需要有额外的中间件。所以Dubbo专注于服务治理;Spring Cloud关注于微服务架构生态。
点赞 5
评论 1
全部评论
推荐
最新
楼层
国泰君安
校招火热招聘中
官网直投
相关推荐
kun1224
06-09 19:49
东北大学 计算机类
大龄应届生何去何从
背景农村出来的自己眼界十分狭窄,年少的自己不知道世界如何运行,进入大学后没有了目标,不知道如何努力,也放纵了自己,蹉跎了大好岁月后面幡然醒悟,也找到了一点小目标,学习编程,再后来觉得需要提升自己的学历,经过边工作边考研,到辞职全职考研,考上了一所末流985最近投了一些大厂的暑期实习,简历也都因为年龄原因被刷,安慰自己这都很正常,继续向前走就行了,但后面中国银行的暑期实习简历也被刷了,就有点绷不住了此刻深感人生之艰难,就像那不息之长河,不求有东去大海之志,但求能做自己喜欢的事情,亦是不易人生行至此阶段,仍然不知该如何向前走,遂在此发帖,请各位交流指点。现状教育背景:双非本985硕年龄:1993....
鼠鼠酱:
技术基本不会考虑你了,本科不行,年龄偏大加班的话,你也吃不消,肯定更倾向于要年轻的牛马,去试试运维或者产品吧,别死磕技术了
牛客帮帮团来啦!有问必答
牛客在线求职答疑中心
点赞
评论
收藏
分享
屋顶的闪闪星光
06-11 22:28
全栈开发
211本科生是怎么卷进互联网大厂的?
2022年之前的时候,各大头部互联网公司每到校招季就跟打仗一样,用尽办法去抢计算机相关专业每年那十来万的硕博毕业生,只管掐尖招人,因为大家的业务都在飞速增长,想象空间也很大,没人在乎成本。 在那种环境下,像小闪这类西南末流211毕业的本科生是很难进到头部互联网大厂的。 但现在来看,形势似乎发生了一些变化,以小闪在北京两家头部互联网大厂实习的观察来看,公司开始宣导本科优先的逻辑。 我跟小闪一起讨论这个问题时猜测了几种可能性: 1、本科生的待遇更低。校招面试属于批发价,所有人都被简单地分成几档,本科生大部分都在最低档,当然也是价格最便宜的那种,白菜嘛。 2、本科生够用了。在互联网大厂...
校招过来人的经验分享
牛客在线求职答疑中心
点赞
评论
收藏
分享
安静的coder在吃瓜
05-31 00:37
工商管理类
现在工作真的难死了。就想找个底薪1万左右的销售。都找不到
点赞
评论
收藏
分享
26加瓦鼠鼠
05-07 08:56
莆田学院 计算机类
够了
😫 #沉淀# #黑皮体育生#
点赞
评论
收藏
分享
才华横溢的牛肉丸
06-13 21:15
C++
建行金融科技岗是真的香
建行总行在四大行中是薪酬水平较高的银行。在后台部门刚进入时,起薪大约在20万元左右,经过两年的基层轮岗后,进入好的部门的年收入可能达到28-30万元。对于硕士毕业生而言,工作3-5年后的税后收入,包括公积金在内,大约在35万元左右。在职位没有变动的情况下,之后的收入增幅不大,大约在35-40万元左右。然后北京分行的新员工在首年的年薪在税前大约12万元左右,前半年只有基础工资,后半年加上绩效,绩效与业绩挂钩;基础工资每月约为7千元,次年起,将根据个人能力而获得更多的收入,平均年薪大约在22-24万元左右,如果在营销方面做得好,就能获得更高的收入。金融科技岗位的实习期为前半年,实习期的薪资为每月8...
投递中国建设银行等公司7个岗位 >
点赞
评论
收藏
分享
点赞
收藏
评论
分享
回复帖子
提到的真题
返回内容
全站热榜
1
...
5000字说透简历和面试核心要点
2.2W
2
...
手上只有1个看不上的实习offer要不要去?
5432
3
...
你怎么看今年的秋招?预测一波
5322
4
...
除了互联网,还能关注哪些公司
5212
5
...
6.13校招&实习招聘信息汇总
5166
6
...
关于实习的转正、边秋招、没实习的相关问题
4008
7
...
oppo VS 京东
2378
8
...
好未来面试记录
2324
9
...
华为许愿
2281
10
...
重庆移动实习
2072
正在热议
#
牛客帮帮团来啦!有问必答
#
1326472次浏览
18666人参与
#
非技术岗薪资爆料
#
53116次浏览
730人参与
#
极具前瞻性,现代汽车编程题
#
9380次浏览
186人参与
#
和牛牛一起刷题打卡
#
44474次浏览
3572人参与
#
写简历别走弯路
#
360052次浏览
4535人参与
#
我发现了面试通关密码
#
409125次浏览
7308人参与
#
OPPO开奖
#
58970次浏览
852人参与
#
产品每日一题
#
1625次浏览
93人参与
#
来聊聊你目前的求职进展
#
229696次浏览
2905人参与
#
华子oc时间线
#
11165次浏览
60人参与
#
投递实习岗位前的准备
#
753185次浏览
13143人参与
#
如果可以选,你最想从事什么工作
#
219603次浏览
3398人参与
#
晒一晒我的offer
#
4029214次浏览
60388人参与
#
国企vs私企,你更想去?
#
34461次浏览
401人参与
#
我想象的工作vs实际工作
#
116695次浏览
1806人参与
#
软件开发2024笔面经
#
1570047次浏览
36084人参与
#
硬件兄弟们 甩出你的华为奖状
#
37879次浏览
224人参与
#
24届软开秋招面试经验大赏
#
1238523次浏览
18675人参与
#
互联网公司评价
#
105654次浏览
1371人参与
#
参加过提前批的机械人,你们还参加秋招么
#
16592次浏览
382人参与
#
百度工作体验
#
31870次浏览
315人参与
#
机械制造笔面经
#
11337次浏览
331人参与
牛客网
牛客企业服务