Dubbo 在 K8s 下的思考

作者 | 曹胜利  Apache Dubbo PMC

导读:Dubbo 作为高性能 Java RPC 框架的刻板印象早已深入人心,在 Cloud Native 的架构选型上,Spring Cloud 或许才是业界的优先选择。实际上,Dubbo 已经悄然地衍进为 Cloud Native 基础设施,不仅承袭过去 RPC 时代的荣耀,而且也完善了现有基础设施的缺失。自从容器和 K8s 登上舞台之后,给原有的 RPC 领域带来了很大的挑战,本文主要讲述 RPC 领域遇到的问题,以及 RPC 怎么去拥抱 K8s 的一些思考。

K8s介绍

Kubernetes 是一个开源的,用于管理云平台中多个主机上的容器化的应用, Kubernetes 的目标是让部署容器化的应用简单并且高效, Kubernetes 提供了应用部署、规划、更新、维护的一种机制。Kubernetes 简称 K8s。

在 Kubernetes 中,最小的管理元素不是一个个独立的容器,而是 Pod 。Pod 的生命周期需要注意以下几点:

  • 容器和应用可能随时被杀死;
  • Pod Ip 和主机名可能变化 (除非使用 StatefulSet 进行定制);
  • 写到本地的磁盘的文件可能消失,如果想不失效,需要用存储卷。
应用 & 容器 & Pod 的关系
  • 应用部署在容器中,一般情况下一个应用只部署在一个容器中;
  • 一个 Pod 下可以包含一个或多个容器,一般情况下一个 Pod 只建议部署一个容器。下列场景除外:
    • side car;
    • 一个容器的运行以来与本地另外一个容器。如一个容器下应用负责下载数据,另外一个容器下应用向外提供服务。
Service

如果一些 Pods 提供了一些功能供其它的 Pod 使用,在 Kubernete 集群中是如何实现让这些前台能够持续的追踪到这些后台的?答案是:Service 。

Kubernete Service 是一个定义了一组 Pod 的策略抽象,这些被服务标记的 Pod 一般都是通过 label Selector 决定的。Service 抽象了对 Pod 的访问。

默认的 Service ,通过一个集群 IP 获取 A Record 。但是有时需要返回所有满足条件的 Pod IP 列表,这时候可以直接使用 Headless Services 。参考:https://kubernetes.io/推荐书籍:kubernetes in action

RPC 介绍和分析

随着微服务的普及,应用之间的通信有了足够多的成熟方案。

  • Dubbo 在 2011 年开源之后,被大量的中小型公司采用;
  • 在 Spring Boot 推出之后,Spring 逐渐焕发出第二春,随即 Spring Cloud 面世,逐渐占领市场,在中国市场中,和 Dubbo 分庭抗争;
  • gRPC 是 Google 推出的基于 Http2 的端到端的通信工具,逐渐在 K8s 市场上占据统治地位,如 etcd,Istio 等都采用 gRPC 作为通信工具;
  • Service Mesh 从开始概念上就火热,现在逐渐走向成熟;
  • Istio + Envoy (其他 sidecar )逐渐开始走上舞台。

应用开发者视角

从功能层面来说,对开发者有感知的功能有:

  • 服务实现
  • 服务暴露(注解或配置)
  • 服务调用(注解或配置)
  • 服务治理等

从选型角度会关注以下几点:

  • 易用性(开发易用性和开箱即用)
  • 性能
  • 功能
  • 扩展性等

框架开发者视角

关键流程:

  • 服务暴露
  • 服务注册
  • 服务发现
  • 服务调用
  • 服务治理

关键知识点:

  • 序列化
  • 网络通信
  • 服务路由
  • 负载均衡
  • 服务限流
  • 熔断
  • 降级等服务治理

主流技术实现

Dubbo / HSF

  • Dubbo 提供了面向接口的远程方法调用。应用开发者定义接口,编写服务并暴露;
  • Client 端通过接口进行调用;
  • Dubbo 注册服务的维度是接口维度,每个接口会在注册中心写入一条数据;
  • Dubbo 支持条件路由,脚本路由,Tag 路由等。这些路由规则都是强依赖于 IP 地址。

备注:Dubbo 和 HSF 的大部分机制都是相似的,所以下面都以 Dubbo 作为方案进行讨论。

SpringCloud

Spring Cloud 通过 Rest 形式进行网络调用。应用开发者可以自己编写暴露 Rest 服务,如 springmvc 。

Spring Cloud 里的服务注册是应用维度( Eureka ),Client 端和 Server 端通过约定的方式进行通信。

Spring Cloud 提供了一套标准 API ,而其中 Netflix 是其中的佼佼者,对这套 API 进行了实现,对大部分开发者来说,可以回直接依赖和使用 Netflix ,所以可以说是 Netflix 提供成了 Spring Cloud 的核心。但是作为商业公司对开源投入往往会多变,如 Eureka 已经体制维护。gRPC

gRPC 是一个基于 HTTP/2 协议设计的 RPC 框架,它采用了 Protobuf 作为 IDL。gRPC 作为端到端的通信方案,可以解决现在的多语言问题。

gRPC 本身不提供服务注册,服务治理的功能。但现在可以看到 gRpc 有趋势往这方面扩展的野心。

K8s

K8s 体系里暂时没有公允的通信框架,一般推荐 gRPC 作为 RPC 框架。

K8s 体系的默认情况下, Pod 的 IP 是变化的,所以 Pod 和 Pod 之间需要通信的话,有几种方式:

  • Service+DNS:新建一个 Service ,可以通过标签选择到一组 Pod 列表,这个 Service 对应一个不变的集群 IP ;Client 端通过 DNS 方式或者直接访问集群 IP。这个集群 IP ,约等于实现了负载均衡 ( iptable 方式);
  • headless service:headless service 和上面的 service 的区别是,它不提供集群 IP ,通过主机名的形式获取一组 IP 列表,Client 端自己决定访问哪个Pod。

Istio + Envoy

Istio 的控制层会向 K8s 的 Api server 请求并监听 pod 信息,service 信息等信息。这样 Istio 中就有了完整的 K8s 集群中的 pod,service 等的完整信息。如果

K8s 集群中有信息变更,Istio 中也可以得到通知并更新对应的信息。Envoy 作为 Proxy 一个最常见的实现,以 Envoy 作为例子简单介绍。Envoy 通过查询文件或管理服务器来动态发现资源。对应的发现服务及其相应的 Api 被称作 xDS 。协议内容包括 LDS、RDS、CDS 等等。参考资料:Service Mesh 介绍:https://www.infoq.cn/article/pattern-service-meshIstio 路由规则:https://istio.io/docs/tasks/traffic-management/request-routing/备注:上述知识是通过查阅资料( Istio 官网),以及和集团 Service Mesh 同学沟通获得。如有问题,欢迎指正。

小结

遇到的问题和挑战

Spring Cloud 和 Dubbo 的共生

Dubbo 默认是基于 TCP 通信,Spring Cloud 大部分基于 Rest 请求。在阿里云实施商业化过程中,发现大量公司需要 Spring Cloud 应用和 Dubbo 进行通信,社区主要依靠 Dubbo 上增加一层网关来解决。

是否有方案进行统一服务注册发现,以及服务调用呢?

基础理论可以参考:https://yq.aliyun.com/articles/585461

Dubbo 在 K8s 场景下的挑战

K8s 下 Pod 的 IP 是变化的 (默认),Dubbo 的服务治理高度依赖 IP 。

K8s 的服务注册通过 Pod 定义完成,服务发现其实是寻找 Pod 的过程。Pod 和应用有一定的对应关系,和 Dubbo 里的接口维度的服务注册发现模型不是很匹配。

Dubbo 在 Service Mesh 场景下的生存空间

Dubbo 需要进行支持裁剪,Dubbo 的大部分功能都可以交由 sidecar ( proxy )来完成。

如果公司已经在部署 RPC 框架,这时候如果需要实施 Service Mesh ,有什么好的过渡方案吗?

问题梳理

服务定义服务怎么定义呢?需要从应用开发者角度看待怎么定义服务。

服务在功能维度对应某一功能,如查询已买订单详情。在 Dubbo 中,对应某个接口下的方法;在 Spring Cloud 和 gRPC 对应一个 http 请求。

如果从面向函数编程角度,一个服务就是一个 function 。在 Java 语言中,class 是一切编程的基础,所以将某些服务按照一定的维度进行聚合,放到某个接口中,就成了一个接口包含了很多的服务。

从 Dubbo 角度来解释下:Dubbo 是面向接口编程的远程通信,所以 Dubbo 是面向服务集的编程,你如果想调用某个服务,必须通过接口的方式引入,然后调用接口中的某个服务。Dubbo Ops 中提供的服务查询功能,其实不是查询单个服务,而是通过查询接口(服务集)之后获得具体的方法(服务)。

而在 Spring Cloud 的世界里,服务提供方会将自己的应用信息( Ip+port )注册成应用下的一个实例,服务消费方和服务提供方按照约定的形式进行 Rest 请求。每个请求对应的也是一个服务。

和 K8s 里的 Service 的区别

K8s 里的 Service 其实是对应到一组 pod+port 列表,和 DNS 联系紧密;用通俗易懂的方式表达:维护了 pod 集合的关系映射。和上面讲的服务是属于不同场景下的两个概念。

按照这个方式定义服务,服务治理的粒度其实也是按照服务粒度,可以针对每个服务设置超时时间,设置路由规则等等。但是服务注册的粒度和服务有什么关系呢?

服务注册粒度

一个应用下包含了很多接口,一个接口下包含了很多服务( Dubbo );或者一个应用包含了很多的服务( Spring Cloud )。分析下应用维度注册和接口维度注册的优缺点。会有一篇独立的文章来阐述应用维度注册的方案。

接口维度注册

优点:

  • 服务查询按照接口维度查询非常方便,实现难度低;
  • 应用拆分或者合并的时候, Client 端(消费者)无需关心,做到了让用户无感。

缺点:

  • 和 K8s 等主流平台的模型对应关系不匹配;
  • 注册的数据量非常大,有一定的性能风险。

应用维度

优点:

  • 和 K8s,Spring Cloud 等模型对应关系一致;
  • 性能上可以得到很大缓解。

缺点:

  • 应用拆分或者合并的时候,Client 端需要感知 (如果想做到不感知,需要框架开发者维护一份接口和应用映射关系的存储);
  • 如果想对用户保持 Dubbo 原有的接口维度的查询,需要较多的工作量来保证;
  • 对用户透明度有所减少,需要在 OPS 上提供其他一些工具。如供应用开发者可以查看具体某个 IP 是否提供了某个服务等等。

Dubbo 和 Spring Cloud目标:

  • Dubbo 和 Spring Cloud 的服务发现进行统一;
  • Dubbo 和 Spring Cloud 可以互相调用。

服务发现统一Dubbo 改造成应用维度的服务注册。(具体不展开,后面文章说明) 

打通调用

Dubbo 实现中,支持将以 Rest 协议进行暴露,并且让 Spring Cloud 识别。

Dubbo + K8s

在 K8s 已经阐述过,下面的内容也是假设一个应用部署在一个容器里,一个容器部署在一个 pod 里。

接下来方案的讨论,互相之间其实是有关联的,如服务治理可能会影响到服务注册发现,服务查询也不能依赖于服务注册的内容。整个设计的过程是不断优化的过程。下面所说的内容,以 Dubbo 来举例说明。

服务治理

Dubbo 原有体系里的服务治理是强依赖于 IP ,当配置了一套服务治理规则的时候,最后都是基于一个或多个 IP 地址。

到 K8s 体系下之后,要考虑的是 Pod 的 IP 不是固定的。所以当前的路由规则不能满足条件,而且会产生很多规则垃圾数据。K8s 体系下,通过 service 查找 Pod ,是基于 label selector ;通过 deployment 管理 Pod ,其实也是基于 Pod label selector 。所以 pod label selector 是在 K8s 习题中比较通用的解决方案。

以路由规则为例,需要支持一种新的路由规则:label 路由。通过一定条件匹配之后,将结果定位到以 label selector 查询到的 Pod 列表里,而非原来的 ip 列表。

要支持 label 路由,client 端需要获取到 client 端自己的 Pod label 信息,还需要获取到 server pod 列表中每个 Pod 的 label 信息。

应用获取当前 Pod 的信息方式:
  • Pod 定义环境变量,应用获取;Dubbo 提供对环境变量读取的支持,Pod 中需要按照 Dubbo 定义的环境变量设置具体的 pod 信息。
  • 通过 Downward API 传递 Pod 信息;Dubbo 需要提供对 Downward 的目录读取,Pod 中需要定制 downward 的对应配置。
  • 通过 API Server 获取数据;最强大的方式,但是应用需要强依赖于 API Server 。
应用获取其他 Pod 的信息方式:
  • 通过调用其他 Pod 的服务获取;依赖于应用能获取自身的 Pod 信息,同时将自身的 Pod 信息暴露成服务( rest 或 dubbo 协议)。client 端通过调用对用的 Pod 获取到对应 Pod 的完整信息。
  • 通过 Api server 获取数据;很强大,但增加了对 Api server 的依赖。

服务注册和发现

K8s 体系下,RPC 服务发现有以下几种方式:

  • 注册机制:将 IP 写入注册中心,用心跳保持连接;当心跳停止,从注册中心删除;
  • 利用 Service+DNS :新建一个 Service ,可以通过标签选择到一组 Pod 列表,这个 Service 对应一个不变的集群 IP ;Client 端通过 DNS 方式或者直接访问集群 IP 。这个集群 IP ,约等于实现了负载均衡 ( iptable 方式);
  • 利用 headless service(DNS) :headless service 和上面的 service 的区别是,它不提供集群 IP ,通过主机名的形式获取一组 IP 列表,Client 端自己决定访问哪个 Pod ;
  • api server :Client 端直接请求 api server ,获取到 pod 的列表, Client 自己决定访问 pod 的逻辑。同时获取的时候增加 watch ,api server 会将 pod 的变化信息同步 Client 。

通过拿到 Server 端的 IP 或者 host ,Client 端就可以发起  http 或者其他协议的请求。

下面介绍符合 Dubbo 的可行方案:

1. Dubbo + Zookeeper pod cluster (HSF+CS cluster)

这是最简单的方式,Dubbo 本身不需要做任何改造。带来的问题是增加了 Zookeeper 的维护,同时这个方案很不云原生,和 K8s 的体系没有任何关系。

脑暴

上面方案是将 ZooKeeper 作为注册中心,那么是否可以将 K8s 里 service 作为注册中心呢?Dubbo 里每个接口去建立一个 service ,每个应用实例启动过程中去更新 Endpoint 信息,建立 Service-> Endpoint-> IP 列表的关系。这种方案中 K8s service 的定义被改造了,而且定义了过多的 service ,service 的维护管理是个难题。

基于 K8s 的场景

在传统的 RPC 领域,服务分成服务注册和服务发现。在 K8s 领域 pod 和应用是一对一的关系,K8s 本身就提供了 pod 查找的能力,所以一定程度上服务注册其实可以不存在,而只需要服务发现。但是这个其实需要一个前提:Dubbo 需要将服务注册发现的粒度改造成应用维度。在运维层面,将 app=xxx (应用名)写入到 pod 的 label 中。

2. Dubbo + K8s DNS

如果 K8s service 提供了cluster ip ,那么 Dubbo 只负责调用该集群 Ip ,路由和负载均衡的逻辑则交给了 K8s 的 proxy 来完成。此方案削减了 Dubbo 的核心能力。
接下来讨论 headless service 提供的能力。
通过请求 <service>.<ns>.svc.<zone>.  IN A  的方式发起请求获取 IP 列表,但是需要轮询方式不断获取更新的 IP 列表。
服务治理相关的功能,需要在上述服务治理部分中独立支持。
参考:https://github.com/kubernetes/dns/blob/master/docs/specification.md#24—records-for-a-headless-service

3. Dubbo + Api Server

Pod 的容器中部署的 Dubbo 应用,服务注册流程可以直接删除,服务发现功能通过和 Api Server 进行交互,获取 Pod 和 service 信息,同时 watch pod 和service 的变更。通过这种方式之后,服务治理相关的信息也可以通过 Api Server 直接获取。

4. Dubbo + Istio + Envoy

Dubbo 可以直接使用指定 ip+端口 的方式调用同一个 pod 下 Envoy  (也可能是同一个node的Envoy)。Dubbo 将路由规则,负载均衡,熔断等功能交给 Istio 和 Envoy。Envoy 需要支持 Dubbo 协议的转发。所以 Dubbo 需要完成两个事情:本地 IP 直连(现有功能), 多余功能裁剪(暂未实现)。

5. Dubbo + Istio

  • Dubbo 应用不再依赖 Envoy 作为 sidecar ,而是直接和 Istio 进行交互,把 Istio 作为注册中心,作为服务治理的配置中心;
  • Dubbo 需要提供类似的 xDS 协议,在pilot将service的instance转换成dubbo的协议格式;
  • Dubbo 还需要去适配 istio 的一些功能,如健康检查,安全相关的逻辑。具体实现可以参考 Envoy 的实现。

6. Dubbo 和 Istio 在 K8s 体系下共存
这个可选择的方案较多,我提供两种思路,供大家思考:

  • 所有的服务注册通过k8s的机制完成,所有的服务发现通过 Headless service 完成。sidecar 在创建过程中,需要对原有的 K8s service 进行 update;
  • Nacos 作为 Dubbo 的注册中心,并且需要将 K8s 中的数据进行部分中转。Dubbo 应用,将服务注册以应用维度注册到 Nacos ,Istio Pilot 需要识别 Nacos 数据;Istio 的运行机制基本不变,需要将 K8s service instance 的数据写入到 nacos ,供 Dubbo 调用。

7. 云上和云下环境共存 & 云上多集群环境
Istio 提供了跨集群和云上云下的解决方案, kubeFed 作为 K8s 的跨集群解决方案也能起到一定作用。
这个课题的复杂度更加高,心中有了一些答案,期望大家通过上文也有一定的思考。

服务查询

抛出三种方式,供大家思考。

Dubbo 原有方式

Dubbo 原有的服务查询是针对接口的查询,每个接口会有版本号和组别。接口名+版本号+组别确定唯一的服务集合,这个服务集下有对应的服务提供者和服务消费者(接口级依赖),服务提供者是一组 ip+port 列表,服务消费者也是一组 ip+port 列表。

当做了改造成应用级别的服务注册或者直接使用 K8s 自带的 Pod 发现机制的话,需要做一些改造,这部分改造,和前面提到的一样,放到其他文章里单独说明。

只支持应用查询

和 Spring Cloud 类似,支持应用维度的查询。查询到具体应用之后,应用详情下包含了 ip+port 列表,每个 ip+port 其实就是一个应用的实例。点击开每个应用实例,可以查看每个应用的详细信息,详细信息包含了该实例提供了哪些服务。

 接口+应用查询均衡

在原来只支持应用查询的基础上,增加一步:支持查询某个接口对应的应用列表,而大部分接口只属于一个应用。

再点击应用列表下具体的应用之后,会跳到应用详情。

总结

上述讨论的是开源的方案,所以相对历史包袱比较少。对一些大公司想从原有的 RPC 方案切换到云原生的支持,需要考虑更多兼容性和性能,需要付出更大的代价。

云原生的趋势已经势不可挡,在 RPC 领域究竟哪种方案最终能够胜出,现在还言之过早。我相信 Service Mesh 和传统的 RPC  (Dubbo/ gRPC)  都会有自己的一席之地,一切让时间给我们答案吧。

Image placeholder
Feign
未设置
  89人点赞

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

推荐文章
使用kubei一步部署k8s高可用集群(包含docker安装、k8s组件安装、master初始化和加入nodes节点)

kubei(kubernetesinstaller)是一个go开发的用来部署kubernetes高可用集群的命令行工具,该工具可在Windows、Linux、Mac中运行kubei原理:通过ssh连接

从零开始入门 K8s | K8s 的应用编排与管理

作者|张振阿里云高级技术专家一、资源元信息1.Kubernetes资源对象我们知道,Kubernetes的资源对象组成:主要包括了Spec、Status两部分。其中Spec部分用来描述期望的状态,St

瓜子二手车在 Dubbo 版本升级、多机房方案方面的思考和实践

前言随着瓜子业务的不断发展,系统规模在逐渐扩大,目前在瓜子的私有云上已经运行着数百个Dubbo应用,上千个Dubbo实例。瓜子各部门业务迅速发展,版本没有来得及统一,各个部门都有自己的用法。随着第二机

K8s有多热?传统银行转型拥抱Kubernetes案例

Kubernetes已经成为标准的基础设施API,像RedHat、Mesosphere(现在的D2IQ)和Pivotal等供应商都无法避免。如果您希望使企业能够合理构建应用程序,那么Kubernete

从零开始入门 K8s:应用编排与管理

一、需求来源 背景问题 首先来看一下背景问题。如下图所示:如果我们直接管理集群中所有的Pod,应用A、B、C的Pod,其实是散乱地分布在集群中。 现在有以下的问题: 首先,如何保证集群内可用Pod的

AWS vs K8s 是新时代的 Windows vs Linux?

作者:IanMiell是开源程序员、演讲师、作家和博客写手以前……如果你与我一样,年过四十,又在IT行业工作,恐怕还记得每个人使用Windows,一小群但越来越多的人在业余时间埋头编译Linux的年代

超大规模商用 K8s 场景下,阿里巴巴如何动态解决容器资源的按需分配问题?

导读:资源利用率一直是很多平台管理和研发人员关心的话题。本文作者通过阿里巴巴容器平台团队在这一领域的工作实践,整理出了一套资源利用提升的方案,希望能够带给大家带来一些讨论和思考。引言不知道大家有没有过

SpringBoot 整合 Dubbo

1.整合dubbo 有的人或许会说已经有spring-cloud了,你整合dubbo干什么,其实没啥意图,主要就是想整合一下,毕竟dubbo在国内使用的还是很多的,你会一点点总不至于让你显得那么尴尬。

税务信息化跨入大数据云计算时代的思考

现状,目前据了解国税总局执行征收管理、行政管理、决策支持和外部信息等四大类应用系统在全国的推广部署,实施大数据开放与共享的建设与开发,已经完成2个国家级税务处理中心的扩容,包括计算存储资源、系统软件及

分布式场景下Kafka消息顺序性的思考

在业务中使用kafka发送消息异步消费的场景,并且需要实现在消费时实现顺序消费,利用kafka在partition内消息有序的特点,实现消息消费时的有序性。1、在发送消息时,通过指定partition

Dubbo 毕业,成为 Apache 基金会顶级项目

Dubbo发展史一览2011年10月27日,阿里巴巴开源了自己服务化治理方案的核心框架Dubbo,服务治理的设计理念开始逐渐在国内软件行业中落地,并被广泛应用。自开源后,许多非阿里系公司选择使用Dub

Dubbo 稳定性案例:Nacos 注册中心可用性问题复盘

问题描述上周四晚刚回到家,就接到了软负载同学的电话,说是客户线上出了故障,我一听”故障“两个字,立马追问是什么情况,经过整理,还原出线上问题的原貌:客户使用了Dubbo,注册中心使用的是Nacos,在

eBay邓明:dubbo-go 中 metrics 的设计

最近因为要在Apache/dubbo-go(以下简称dubbo-go)里面实现类似的这个metrics功能,于是花了很多时间去了解现在Dubbo里面的metrics是怎么实现的。该部分,实际上是被放在

案例诊断:“交易耗时8S”缉凶记

背景某日上午,小集购买a产品失败,页面弹出“系统异常,请稍后重试”的报错,便联系了技术团队的开发小成。“小成,我刚才尝试买a产品一直显示系统异常,是不是有什么问题呢?”开发小成接到电话后,迅速着手排查

SpringBoot整合RabbitMQ

SpringBoot整合RabbitMQSpringBoot框架已经提供了RabbitMQ的使用jar包,开发人员在使用RabbitMQ的时候只需要引用jar包简单的配置一下就可以使用RabbitMQ

SpringBoot连接多RabbitMQ源

在实际开发中,很多场景需要异步处理,这时就需要用到RabbitMQ,而且随着场景的增多程序可能需要连接多个RabbitMQ。SpringBoot本身提供了默认的配置可以快速配置连接RabbitMQ,但

自动驾驶思考:仿真系统构建

如何构建自动驾驶仿真系统? 仿真最主要的目的是:通过模拟真实环境和构建汽车模型,找出自动驾驶过程中可能出现的问题。 那么如何构建自动驾驶仿真系统呢?目前主流的实现方式是通过游戏引擎来模拟真实环境,通

技术大牛创业失败,原来是缺少这套思考框架

2016年以前,大众媒体对技术人创业的报道可以总结为一句话:“为何技术人创业更容易成功?”,2018年后,这个总结变成了“一个程序员创业的血泪史”。这样的转变令人哭笑不得。最近几年,技术创业者多到让

实践和思考的重要意义(论软件代码设计)

感触 最近这段时间,包括以前,经常听到,程序员们大谈设计模式,这个话题并不陌生,面试必问的问题,活了这么多年,我就一直没搞清楚,为啥面试官喜欢问这个问题。如果一个面试官喜欢问这种问题,我觉得也没啥意思

实践和思考的重要意义(论软件代码设计)

感触最近这段时间,包括以前,经常听到,程序员们大谈设计模式,这个话题并不陌生,面试必问的问题,活了这么多年,我就一直没搞清楚,为啥面试官喜欢问这个问题。如果一个面试官喜欢问这种问题,我觉得也没啥意思。

工程师笔记:我对数据库系统云原生化的一些思考

作者|张敏(于期)阿里云智能高级技术专家划重点我眼中的云原生我认为的云原生关键能力我眼中的云原生化技术手段我对数据库云原生化的思考伴随着云原生技术越来越热门,阿里内部关于CloudNative、Ser

人社部大数据应用场景思考

文/涵诚人社部尹蔚民部长在2017年5月全国“互联网+人社”座谈会指出,要充分运用大数据手段,通过“互联网+人社”,实现决策科学、管理精准化、服务人本化,人社的统计数据对于服务决策、研究政策、支撑事业

redis实践及思考

导语:当面临存储选型时是选择关系型还是非关系型数据库?如果选择了非关系型的redis,redis常用数据类型占用内存大小如何估算的?redis的性能瓶颈又在哪里?背景前段时间接手了一个业务,响应时间达

SACC 2019:达梦数据库推进实践与思考

2019年10月31日~11月2日,由IT168旗下ITPUB企业社区平台主办的第十一届中国系统架构师大会(SACC2019)在北京成功召开。本届大会继续沿用四大主线并行的演讲模式,设置业务系统架构设

万万没想到,HashMap默认容量的选择,竟然背后有这么多思考!?

集合是Java开发日常开发中经常会使用到的,而作为一种典型的K-V结构的数据结构,HashMap对于Java开发者一定不陌生。在日常开发中,我们经常会像如下方式以下创建一个HashMap:Map ma