在将dubbo框架里的服务提供者迁移进k8s时,有几个注意事项: 1, 要为默认情况下,dubbo会将k8s里的pod ip地址作为注册服务的地址,所以这个地址需要被改写(ip测试过,行得通,而dns待测试). 2, Tomcat启动的端口需要与xxxx-dubbo.xml文件里的定义一致. 3,   同时,要将k8s的service和deploy的容器端口和nodePort端口都映射为同一个端口才可以.

## 说在前面 大概是三年前,因一些原因公司原项目最初为单体结构部署,所有业务模块都在一个项目里面,而后随着业务的不断膨胀以及模块之间的耦合,导致后面增加或修改一些简单业务时的成本都会变的极大.新入职的同事更是苦不堪言,学习代码的成本极高.基于这些原因,就开始了后面漫长的架构改造旅途. ## 这么多微服解决方案,到底选哪个? #### 1.介绍 ![file](https://img2018.cnblogs.com/blog/820767/202001/820767-20200101211354

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

1.注册中心概述 ​ 在Dubbo微服务体系中,注册中心是其核心组件之一.Dubbo通过注册中心实现了分布式环境中各微服务之间的注册与发现,是各分布式节点之间的纽带.其主要作用如下: 动态加入.一个服务提供者通过注册中心可以动地把自己暴露给其他消费者,无序消费者逐个去更新配置文件; 动态发现.一个消费者可以动态地感知新的配置.路由规则和新的服务提供者,无需重启服务使之生效: 动态调整.注册中心支持参数的动态调整,新参数自动更新到所有相关服务节点: 统一配置.避免了本地配置导致每个服务的配置不一致

Dubbo 微服务系列(03)服务注册 [TOC] Spring Cloud Alibaba 系列目录 - Dubbo 篇 1. 背景介绍 图1 Dubbo经典架构图 注:本图来源 Dubbo官方架构图 表1 节点角色说明 节点 角色说明 Provider 暴露服务的服务提供方 Consumer 调用远程服务的服务消费方 Registry 服务注册与发现的注册中心 Monitor 统计服务的调用次数和调用时间的监控中心 Container 服务运行容器 在 Dubbo 微服务体系中,注册中心是其

前言 最近翻看以前写的 PPT, 发现了在2019年做的一次技术分享,关于 Java 问题排查,由于没什么公司机密可言,整理下分享给大家~ 线上问题处理流程 直接放PPT截图吧,现在看来依然不过时 问题排查 可从三个方面入手 知识:有些问题,思考一下就有答案,就像传说中多隆那样,回忆下就知道第83行代码有问题~ 工具:当然不是每个人都能做到过目不忘,也有可能这代码完全不是你写的,这时就需要靠工具来定位问题 数据:程序运行时产生的数据,也能提供很多线索 知识 知识有很多方面,这里简单列举一下: 语

超出容器的内存限制 只要节点有足够的内存资源,那容器就可以使用超过其申请的内存,但是不允许容器使用超过其限制的 资源.如果容器分配了超过限制的内存,这个容器将会被优先结束.如果容器持续使用超过限制的内存, 这个容器就会被终结.如果一个结束的容器允许重启,kubelet就会重启他,但是会出现其他类型的运行错误. 本实验,我们创建一个Pod尝试分配超过其限制的内存,下面的这个Pod的配置文档,它申请50M的内存, 内存限制设置为100M. memory-request-limit-2.yaml ap

1.登录到jenkins,新建一个项目 2.新建流水线 3.设置保留的天数及份数 4. 添加参数 # 参数 . name: git_repo type: string description: 项目在git版本仓库的地址,如 https://gitee.com/xxx/dubbo-demo-service.git . name: app_name type: string description: 项目名称,如 dubbo-demo-service . name: git_ver type: s

1.基础架构 主机名 角色 ip HDSS7-11.host.com K8S代理节点1,zk1 10.4.7.11 HDSS7-12.host.com K8S代理节点2,zk2 10.4.7.12 HDSS7-21.host.com K8S运算节点1,zk3 10.4.7.21 HDSS7-22.host.com K8S运算节点2,jenkins 10.4.7.22 HDSS7-200.host.com K8S运维节点(docker仓库) 10.4.7.200 Dubbo微服务概述  实验架构

Kubernetes K8S之CPU和内存资源限制详解 Pod资源限制 备注:CPU单位换算:100m CPU,100 milliCPU 和 0.1 CPU 都相同:精度不能超过 1m.1000m CPU = 1 CPU. 官网地址: 1 https://kubernetes.io/zh/docs/tasks/configure-pod-container/assign-cpu-resource/ 2 https://kubernetes.io/zh/docs/tasks/configure-p

需要这样一套日志收集.分析的系统: 收集 -- 能够采集多种来源的日志数据 (流式日志收集器) 传输 -- 能够稳定的把日志数据传输到中央系统 (消息队列) 存储 -- 可以将日志以结构化数据的形式存储起来 (搜索引擎) 分析 -- 支持方便的分析.检索方法,最好有GUI管理系统 (前端) 警告 -- 能够提供错误报告,监控机制 (监控工具) 优秀的社区开源解决方案 ---- ELK Stack E ----- ElasticSearch L ----- LogStash K ----- Kib

1.登录到jenkins,新建一个项目 2.新建流水线 3.设置保留的天数及份数 4.添加第一个参数:设置项目的名称 5.添加第二个参数:docker镜像名称 6.添加第三个参数:项目所在的git中央仓库地址 7.添加第四个参数:项目在git仓库的对应分支或版本号 8.添加第五个参数:添加镜像标签 9.添加第六个参数:编译项目的位置 10.添加第七个参数:项目编译完成后,产生jar/war包的位置 11.添加第八个参数:编译所要使用的命令 12.添加第九个参数:使用哪个底包 13.添加第十个参数

基础架构 主机名 角色 IP地址 mfyxw10.mfyxw.com K8S代理节点1,zk1 192.168.80.10 mfyxw20.mfyxw.com K8S代理节点2,zk2 192.168.80.20 mfyxw30.mfyxw.com K8S Node节点1,zk3 192.168.80.30 mfyxw40.mfyxw.com K8S Node节点2,jenkins 192.168.80.40 mfyxw50.mfyxw.com K8S运维节点(docker仓库) 192.168

k8s交付实战-流水线构建dubbo服务 目录 k8s交付实战-流水线构建dubbo服务 1 jenkins流水线准备工作 1.1 参数构建要点 1.2 创建流水线 1.2.1 创建流水线 1.2.2 添加10个构建参数 1.2.3 添加完成效果如下: 1.2.4 添加pipiline代码 1.3 用流水线完成dubbo-service的构建 1.3.1 选择参数化构建 1.3.2 填写完成效果如下 1.3.3 执行构建并检查 2 交付dubbo-service到k8s 2.1 准备资源清单 2

我们这里的dubbo-consumer是dubbo-demo-service的消费者: 我们之前已经在jenkins配置好了流水线,只需要填写参数就行了. 由于dubbo-consumer用的gitee的私有仓库,需要添加公钥,这里大家可以自己找个client服务来做实验. 下面是我们通过jenkins构建的镜像,已经上传到我们的harbor私有仓库当中了: 这里我们构建了两次,构建了两个镜像,11bb9cd这个用来做模拟生产发版更新实验. 准备资源配置清单: 1.dp.yaml  红色部分根据

使用jenkins创建一个新的项目:dubbo-demo,选择流水线构建 勾选保存构建历史和指定项目为参数化构建项目: 添加构建参数:以下配置项,是王导根据多年生产经验总结出来的甩锅大法: 除了base_image和maven是choice parameter,其他都是string parameter 添加完成后,效果如图: 编写pipeline:仔细查看这个pipeline,里面都是我们上面编写的参数. pipeline { agent any stages { stage('pull') {

首先下载jenkins镜像并上传到我们自己的私有仓库:7-200 # docker pull jenkins/jenkins:2.190.3 # docker tag 22b8b9a84dbe harbor.od.com/public/jenkins:v2.190.3 # docker push harbor.od.com/public/jenkins:v2.190.3 为了适应我们的环境,我们的jenkins不能直接使用,需要进行配置: # mkdir -p /data/dockerfile/

K8S(18)容器环境下资源限制与jvm内存回收 目录 K8S(18)容器环境下资源限制与jvm内存回收 一.k8s中的java资源限制与可能的问题 方案1:通过JVM的Xms和Xmx参数限制 方案2:通过容器的requests和limits参数控制 方案3:容器参数和JVM参数共用 二.解决问题三板斧 1)采用JDK8-191以上的jdk版本 2)使用JVM新的资源限制参数且不相等 3)配置容器的资源限制参数 一.k8s中的java资源限制与可能的问题 与以前单机跑单服务的情况相比,在k8s.

背景 某项目采用微服务架构,dubbo 框架,K8s 方式部署. 其中 HTTP 协议由网关应用统一处理,大部分应用仅提供 dubbo 协议. 目标 应用某个实例(pod)状态异常时,尝试自动重启恢复. 解决 K8s 提供了3种存活探针(livenessProbe),以实现 pod 状态异常时重启. HTTPGetAction 首先排除了,因为上文我们说了,HTTP 访问由网关统一处理,应用本身没有 HTTP 协议. 然后是 TCPSocketAction,该探针仅能确认 dubbo 端口是否为

1.背景 服务架构一般都是从 单体架构 -> 微服务架构 -> 分布式架构 的迭代,我上一家公司就是在业务发展到一定规模时,开始拆老的单体服务,按业务维度拆成多个微服务,服务之间用的是HTTP请求,通常要求接口RT在200ms以内.目前的公司已经是分布式架构了,服务之间接口RT通常要求20ms以内.所以趁着清明节放假的时间,学一学现在开源的RPC框架Dubbo. 2.问题 之前LBS笔记写了怎么用RTree判断点在多边形内:[LBS学习笔记2]RTree判断点在多边形内-Java版本 个人学习