基于Kubernetes部署Apache Zookeeper 有更新!
随着云原生化流行的大趋势,我们的基础组件也需要逐渐上Kubernetes了。Apache Zookeeper作为目前最流行的分布式协调组件,在我们的微服务架构中负责扮演注册中心的角色。在Kubernetes中运行Zookeeper集群是很有意义的,可以利用其原生的弹性扩缩容、高可用特性。
随着云原生化流行的大趋势,我们的基础组件也需要逐渐上Kubernetes了。Apache Zookeeper作为目前最流行的分布式协调组件,在我们的微服务架构中负责扮演注册中心的角色。在Kubernetes中运行Zookeeper集群是很有意义的,可以利用其原生的弹性扩缩容、高可用特性。
我们来说说 kubernetes 的服务发现。那么首先这个大前提是同主机通信以及跨主机通信都是 ok 的,即同一 kubernetes 集群中各个 pod 都是互通的。这点是由更底层的方案实现,包括 docker0/CNI 网桥、flannel vxlan/host-gw 模式等,在此篇就不展开讲了。
任务编排是什么意思呢,顾名思义就是可以把"任务"这个原子单位按照自己的方式进行编排,任务之间可能互相依赖。复杂一点的编排之后就能形成一个 workflow 工作流了。
随着这些年微服务的流行,API网关已经成为微服务架构中不可或缺的一环。一方面它承担着服务对外的唯一门户,一方面它提取了许多应用的共性功能。
我们可以使用 zookeeper 作为注册中心来实现服务的注册与发现,curator 框架提供了 curator-x-discovery 扩展实现了开箱即用的服务注册发现,但更多时候我们还是选择自己去实现,那这个时候我们需要额外关注 zookeeper 的 1 个特性,即 wathcer。
最近在建设websocket长连接网关,过程中遇到一件比较奇怪的事情,做下简单的记录。
kubernetes 已经成为容器编排领域的王者,它是基于容器的集群编排引擎,具备扩展集群、滚动升级回滚、弹性伸缩、自动治愈、服务发现等多种特性能力。
Netty 的整体流程相对来说还是比较复杂的,初学者往往会被绕晕。所以这里总结了一下整体的流程,从而对 Netty 的整体服务流程有一个大致的了解。从功能上,流程可以分为服务启动、建立连接、读取数据、业务处理、发送数据、关闭连接以及关闭服务。
Eureka 与 Ribbon 都是 Netflix 提供的微服务组件,分别用于服务注册与发现、负载均衡。同时,这两者均属于 spring cloud netflix 体系,和 spring cloud 无缝集成,也正由于此被大家所熟知。
Istio 现在是 Service Mesh 中最火热的项目了,它主要负责对服务网格中的流量进行管理,包括动态服务发现、服务路由、弹性功能等。它作为 Service Mesh 的控制平面,配合 Envoy 作为数据平面,构成了 Service Mesh 中流量管理体系。
在微服务的应用场景下,服务之间可以通过各种方式与协议进行交互,同时整条链路也会变得比较长。与此同时,我们会希望一些数据在整条链路中进行透传,比如说用作对普通 api 参数的动态补充、链路压测标识或者灰度发布标识等。
最近在做类隔离相关的一些工作,而恰恰之前协助开发同学时也发现会遇到许多类加载相关的异常,并且往往比较难定位与解决。这里简单做一个小总结。
线上故障主要会包括cpu、磁盘、内存以及网络问题,而大多数故障可能会包含不止一个层面的问题,所以进行排查时候尽量四个方面依次排查一遍。
9月26日,在杭州云栖大会上各位专家分享了关于互联网中间件的一些内容。
我司目前 RPC 框架是基于 Java Rest 的方式开发的,形式上可以参考 SpringCloud Feign 的实现。Rest 风格随着微服务的架构兴起,Spring MVC 几乎成为了 Rest 开发的规范,同时对于 Spring 的使用者门槛也比较低。
近来总是会有服务遇到 OOM 的情况,简单定位后发现 rpc 框架内存占用较多,看来是时候需要优化一波了。
在去年写过一篇关于微服务优雅上下线的文章,比较笼统的将了一下微服务保证优雅上下线的一些方式。但随着应用的逐渐 k8s 化,原有的微服务下线会存在一些问题。
当一个单体应用改造成多个微服务之后,在请求调用过程中往往会出现更多的问题,通信过程中的每一个环节都可能出现问题。而在出现问题之后,如果不加处理,还会出现链式反应导致服务雪崩。服务治理功能就是用来处理此类问题的。我们将从微服务的三个角色:注册中心、服务消费者以及服务提供者一一说起。
在我们对微服务架构有了整体的认识,并且具备了服务化的前提后,一个完整的微服务请求需要涉及到哪些内容呢?这其中包括了微服务框架所具备的三个基本功能。
抛去教条性质的解释,从巨石应用到微服务应用,耦合度是其中最大的变化。或是将多个模块中重复的部分进行拆分,或是纯粹为了拆分膨胀的单体应用,这些拆分出来的部分独立成一个服务单独部署与维护,便是微服务了。