kubernetes微服务扩容与新功能版本的发布

微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称,微服务是需要与业务能力相匹配,这种说法完全正确。不幸的是,仍然意味着,如果能力模型粒度的设计是错误的,那么,我们就必须付出很多代价。如果你阅读了Fowler的整篇文章,你会发现,其中的指导建议是非常实用的。在决定将所有组件组合到一起时,开发人员需要非常确信这些组件都会有所改变,并且规模也会发生变化。服务粒度越粗,就越难以符合规定原则。服务粒度越细,就越能够灵活地降低变化和负载所带来的影响。然而,利弊之间的权衡过程是非常复杂的,我们要在配置和资金模型的基础上考虑到基础设施的成本问题。

接下来结合我们的k8s进行对我们的微服务项目进行演示
启动副本本身是无状态的应用,无需考虑服务是否带来的影响
扩容根据副本本身的模版再去创建新的副本
replicas是整个副本的数量,而不是在原基础的副本增加3

[[email protected] k8s]# kubectl scale --replicas=3 deployment stock -n ms
deployment.extensions/stock scaled
[[email protected] k8s]# kubectl get pod -n ms
NAME                       READY   STATUS    RESTARTS   AGE
eureka-0                   1/1     Running   0          21m
eureka-1                   1/1     Running   0          19m
eureka-2                   1/1     Running   0          18m
gateway                    1/1     Running   0          16m
gateway                    1/1     Running   0          16m
order                         1/1     Running   0          11m
portal                         1/1     Running   0          9m31s
product                      1/1     Running   0          11m
stock                          1/1     Running   0          6s
stock                          1/1     Running   0          11m
stock                          1/1     Running   0          6s

新功能上线模拟
在product这个模块下,这里-dev.yml是本地的一个测试环境,修改某个功能比如,那么我们就需要重新构建一下jar包,比如修复bug或者添加代码,我们就得重新构建镜像,但是在k8s中我们只需要对某个模块进行构建就可以了,无需再全部构建,进入分支选择改动的模块,k8s用新的镜像

[[email protected] simple-microservice-dev3]# vim product-service/product-service-biz/src/main/resources/application-dev.yml

开发把代码更新完之后,提交到git、gitlab仓库,我们就需要git clone 拉取目标项目代码到本地
然后构建

[[email protected] simple-microservice-dev3]# cd product-service/
[[email protected] product-service]# ls
pom.xml  product-service-api  product-service-biz
[[email protected] product-service]# mvn clean package -D maven.test.skip=true

为什么可以在这个目录下也可以执行?

[[email protected] product-service]# ls
pom.xml  product-service-api  product-service-biz

因为这里有这个pom.xml,描述了所需的依赖包,都在这里面定义的

然后推送到我们的k8s中,执行这个脚本,将会替换我们新的模块,把新功能推送上去
微服务的新功能发布也不会影响前端等其他模块的使用

[[email protected] k8s]# ./docker_build.sh product-service
[[email protected] k8s]# kubectl get pod -n ms
NAME                       READY   STATUS    RESTARTS   AGE
eureka-0                   1/1     Running   0          70m
eureka-1                   1/1     Running   3          69m
eureka-2                   1/1     Running   3          68m
gateway                    1/1     Running   0          65m
gateway                    1/1     Running   0          65m
order                         1/1     Running   0          60m
portal                         1/1     Running   0          58m
product                      1/1     Running   0          115s
stock                          1/1     Running   0          61m

原文地址:https://blog.51cto.com/14143894/2430372

时间: 2024-10-01 22:10:31

kubernetes微服务扩容与新功能版本的发布的相关文章

041 用户注册功能01--搭建微服务和数据验证功能

1.创建用户中心微服务 用户搜索到自己心仪的商品,接下来就要去购买,但是购买必须先登录.所以接下来我们编写用户中心,实现用户的登录和注册功能. 用户中心的提供的服务: 用户的注册 用户登录 这里我们暂时先实现基本的:注册和登录功能. 因为用户中心的服务其它微服务也会调用,因此这里我们做聚合. leyou-user:父工程,包含2个子工程: leyou-user-interface:实体及接口 leyou-user-service:业务和服务 (1)创建父module (2)创建leyou-use

docker微服务部署之:七、Rancher进行微服务扩容和缩容

docker微服务部署之:六.Rancher管理部署微服务 原文地址:https://www.cnblogs.com/ztone/p/10582192.html

漫谈何时从单体架构迁移到微服务?

面对微服务如火如荼的发展,很多人都在了解,学习希望能在自己的项目中帮得上忙,当你对微服务的庐山真面目有所了解后,接下来就是说服自己了,到底如何评估微服务,什么时候使用微服务,什么时间点最合适,需要哪些技术储备和资源投入等等,这些都是你需要面对和解决的. 本文从单体架构,微服务架构,微服务风险评估,微服务落地条件等几个方面探讨微服务的落地过程,希望对你有所启发. 讲解微服务之前,我们先简单了解下单体架构. 一.单体架构 单体架构的优点: 快速开发和验证想法,证明产品思路是否可行 投入资源和成本,包

atititi.soa  微服务 区别 联系 优缺点.doc

atititi.soa  微服务 区别 联系 优缺点.doc 1. 应用微服务的动机,跟传统巨石应用的比较1 2. 面向服务架构(SOA)  esb2 3. 微服务架构(Microservices)2 4. 微服务架构特征(Characteristics)3 4.1. 通过服务实现组件化 vs   通过库(library)3 4.2.  去中心统一化  vs 统一的技术平台3 4.3. 7. Design for failure3 5. 服务划分有两个原则要遵循:单一职责原则    每个工具都小

SOA 架构与微服务架构的区别

注重重用,微服务注重重写 SOA 的主要目的是为了企业各个系统更加容易地融合在一起. 微服务通常由重写一个模块开始.要把整个巨石型的应用重写是有很大的风险的,也不一定必要.我们向微服务迁移的时候通常从耦合度最低的模块或对扩展性要求最高的模块开始. 把它们一个一个剥离出来用敏捷地重写,可以尝试最新的技术和语言和框架,然后 单独布署.它通常不依赖其他服务.微服务中常用的 API Gateway 的模式主要目的也不是重用代码. 而是减少客户端和服务间的往来.API gateway 模式不等同与 Fac

从Spring Cloud到Kubernetes的微服务迁移实践

写在前面 要出发周边游(以下简称要出发)是国内知名的主打「周边游」的在线旅行网站,为了降低公司内部各个业务模块的耦合度,提高开发.交付及运维效率,我们在 2017 年就基于 Spring Cloud 完成了公司内部业务微服务化的改造,并在 2019 年实现了 Spring Cloud 至 UK8S 平台的迁移.? 本文从要出发的业务架构.Prometheus JVM 监控.基于 HPA 的峰值弹性伸缩.基于 Elastic 的APM链路跟踪及 Istio 服务治理等方面介绍了我们基于UK8S的

为什么 kubernetes 天然适合微服务 (3)

此文已由作者刘超授权网易云社区发布. 欢迎访问网易云社区,了解更多网易技术产品运营经验 四.Kubernetes 本身就是微服务架构 基于上面这十个设计要点,我们再回来看 Kubernetes,会发现越看越顺眼. 首先 Kubernetes 本身就是微服务的架构,虽然看起来复杂,但是容易定制化,容易横向扩展. 如图黑色的部分是 Kubernetes 原生的部分,而蓝色的部分是网易云为了支撑大规模高并发应用而做的定制化部分. Kubernetes 的 API Server 更像网关,提供统一的鉴权

唱吧DevOps的落地,微服务CI/CD的范本技术解读

原文地址:http://www.infoq.com/cn/articles/devops-landing-in-changba?utm_campaign=rightbar_v2&utm_source=infoq&utm_medium=articles_link&utm_content=link_text 作者 钮博彦 刘宇桐 发布于 2017年3月28日. 1.业务架构:从单体式到微服务 K歌亭是唱吧的一条新业务线,旨在提供线下便捷的快餐式K歌方式,用户可以在一个电话亭大小的空间里

微服务说的局限性

导读 关于微服务的优势和劣势已经有过太多的讨论,不过我仍然看到很多成长型初创公司对它进行着"盲目崇拜".冒着"重复发明轮子"的风险(Martin Fowler 已经写过"Microservice Premium"的文章),我想把我的一些想法写下来,在必要的时候可以发给客户,也希望能够帮助人们避免犯下我之前见过的那些错误. 在进行架构或技术选型时,将网络上找到的一些所谓的最佳实践文章作为指南,一旦做出了错误的决定,就要付出惨重的代价.如果能够帮助哪