ImageVerifierCode 换一换
格式:DOCX , 页数:10 ,大小:475.42KB ,
资源ID:2033273      下载积分:3 金币
快捷下载
登录下载
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。 如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝    微信支付   
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【https://www.bdocx.com/down/2033273.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录   QQ登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(微服务架构的部署.docx)为本站会员(b****2)主动上传,冰豆网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知冰豆网(发送邮件至service@bdocx.com或直接QQ联系客服),我们立即给予删除!

微服务架构的部署.docx

1、微服务架构的部署微服务架构的部署本文从以下几个方面简要说明微服务架构项目的实践经验:架构选型、开发测试环境下的相关工具支持、人员分工与开发部署流程、相关设计与须知。最后,将根据实践经验讨论提高微服架构下的开发和运维效率的切实需求,进一步理清本项目所实现的容器服务管理平台的完善性需求。本项目是一个企业级的容器服务管理平台,该平台的功能是基于容器实现的应用运行环境管理,以与应用开发阶段的持续集成和持续发布。简单的理解该平台的核心功能之一就是管理复杂应用的开发和运维环境,提高微服务架构下的开发和运维效率。项目的开发背景如下:首先,该系统具有典型分布式应用系统特征:该平台所运行的服务器配置不高,例如华

2、为RH1288这类低配置服务器,允许硬件失败;系统平台要求可根据实际用户数的规模进行伸缩部署,保证硬件资源的合理利用;由于系统平台之上需要运行若干企业应用的开发和运行环境,可靠性是非常重要的,不允许单点失效。其次,本系统功能复杂,从架构的角度需要将系统分成多个层次和若干个子系统。不同的层次、子系统根据具体情况需要采用不同的开发语言,由不同的开发小组完成。第三,项目组成员由几个城市的异地团队协同开发,统一的开发环境和协同工具是必不可少的。针对上述项目背景的考虑,本项目选择基于微服务架构进行项目开发。开发、测试、部署使用到的工具集“工欲善其事、必先利其器”,借助适合的流程和相关工具集,才能提高微服

3、务架构下的应用开发效率。本项目利用DevOPs流程并选用一套相关工具集实现应用开发管理,提高开发、测试、部署的效率。代码库:本项目使用分布式代码库Gitlab,它的功能不限于代码仓库,还包括reviews(代码审查), issue tracking(问题跟踪)、wiki等功能,是代码管理和异地团队沟通、协作工具的首选。Docker镜像仓库、Docker:本项目用容器贯穿整个软件开发流程,以容器作为应用发布的载体,应用的开发环境和测试发版环境都运行在Docker容器中。对于复杂的开发和运维环境管理Docker具有先天的优势,目前国外的互联网公司有大多数都已经将Docker应用到了他们的开发或者生

4、产环境中了。K8s:本项目采用Kubernates作为容器调度管理的基础环境,开发环境、测试环境的Docker容器都由K8s负责调度管理。Jenkins:快速的部署发布离不开老牌持续集成明星Jenkins,本项目通过Jenkins任务构建代码、将应用打包成Docker镜像,最终发布到K8s环境中将容器运行起来。Shell脚本:编写Shell脚本将项目打分支、发布应用等开发阶段的配置管理工作自动化,降低运维门槛、提高配置管理和运维的效率。WIKI:Gitlib上的WIKI功能相对简陋,因此项目组选择dokuwiki作为异地团队协作和沟通的工具,团队成员可以将设计文档、知识分享文档、公告信息等信息

5、可以更新到wiki上,便与协同开发。禅道:为了便于开发计划、开发任务和bug关联起来,本项目使用禅道进行开发任务和bug管理。人员分工与开发流程微服务架构应用的开发、部署的复杂度都是远大于单体式应用的,靠运维人员手工的配置管理显然是难于应付了。DevOps主以自动化任务处理方式实现软件交付与基础设施更新,可以说是微服务架构应用开发和运维的必要条件,本项目采用DevOps的理念的开发流程进行开发。实现部署和运维的自动化需要工具,同时DevOps强调软件开发者与其他IT员工与管理层间的协作与沟通,因此明确的人员分工和开发流程是与工具同样重要的因素。通俗的说,就是有了工具,大家要知道怎么使用工具,并

6、且愿意使用工具才能真正达到提高研发效率的目的。项目组的主要工作成员无非也是做开发、测试和系统管理三类工作,这里只说明与传统的企业应用开发过程中三类人员所做的工作略有不同的工作容。开发人员:a) 开发者做开发设计,需要将涉与到接口部分设计更新到wiki上,供调用者评审和调用。b) 开发者除了编写程序逻辑外,还需要注意编写单元测试用例,因为分布式应用联调相对复杂,先做在编写单服务时做好了测试再联调能够提高开发效率。c) 由于本项目是采用Docker容器作为发布载体的,开发者可能需要修改DockerFile模板里的部分参数,便于部署阶段能将编译后的代码打包到镜像中。相对于传统的开发方式,这是对开发者

7、额外的要求。让所有开发者懂Dockerfile似乎要求也有点高,其实每个子项目中的DockerFile与脚本一般是在搭建项目框架时,主要系统配置管理员编写的好的模板,若开发人员不懂相关技术,也可以跟配置管理员沟通需求,由配置管理员修改相关文件。测试人员:测试人员的工作没有什么特别,只是需要注意除了每个Sprint阶段的测试外,还需要配合开发人员持续集成的测试;系统配置管理人员:一般DevOps的开发方式是依赖于云基础平台以与自动化发布工具的,因此相对于传统开发方式,对系统配置管理者的技术要求会比较低。但是,我们的项目开发目的就是构建一个能支撑DevOps流程的平台,其开发本身还不具备相应的平台

8、基础。因此,我们项目最初的系统配置管理工作是由架构师来做的,主要需要做如下这些事:a) 部署运行项目组开发需要用到公共的服务组件、例如zookeeper注册中心、Docker Registry镜像仓库、数据库等;b) 为子项目编写在git上打分支的脚本,便于测试发版的时候打分支;c) 编写各类型应用发布部署成镜像的Dockerfile;d) 制作或者在网上找到现成的开发所需环境的Docker镜像,并且Push到项目开发使用的私有镜像库中;e) 编写Shell脚本实现将子项目打包成Docker镜像,并且Push到镜像仓库中。f) 在Jenkins上配置自动编译或者部署任务,实现持续集成和部署。本

9、文将对项目的开发、部署联调以与测试发版流程和规做简要说明,并提供项目各个阶段使用到的部分自动化脚本工具示例。图 1 项目持续集成和部署流程代码分支管理:如下图,在git上创建的每一个项目都需要至少建立develop和master两个分支。开发人员只有权限把代码提交到develop分支上,平时的持续集成和联调都从develop分支上获取代码。 每个Sprint阶段测试发版时,配置管理员从develop分支上创建一个用于测试的release分支。当测试修改bug时,开发人员只把修改后的代码提交到对应的测试Release分支上。当测试版本稳定后,由配置管理员将代码合并到Master分支中。自动部署和

10、发布:项目借助于Shell脚本、Dockerfile、K8s配置文件和Jenkins任务实现了自动化的持续集成和部署。配置管理员在项目目录下编写的脚本文件结构如图2所示。a) 创建分支的shell脚本,示例见附件1;#!/bin/bashif -z $1 ; thencat EOFUsage:branch-release.sh EOFexit 1fiDEPLOY_VERSION=$1RP_FILES=(subproject1/kube-rc.yaml subproject1/pom.xml subproject1/Makefile)if -z $(git branch -a | grep -e

11、 /$DEPLOY_VERSION$) ; thengit branch $DEPLOY_VERSIONgit checkout $DEPLOY_VERSIONelsegit checkout $DEPLOY_VERSIONgit pullfi#替换k8s配置文件中环境指向,从开发切换到测试#替换掉pom.xml文件中的SNAPSHOT为release版本号#替换掉makefile中发布的镜像Tag的latest为release版本号for f in $RP_FILES; dosed -i -e s#api.devproject.#api.testproject.#g -e s#0.0.1-S

12、NAPSHOT#$DEPLOY_VERSION-SNAPSHOT#g -e s#latest#$DEPLOY_VERSION#g $fdonegit commit -a -m Create Branch $DEPLOY_VERSIONgit push origin $DEPLOY_VERSIONb) Dockerfile示例文件,将Java dubbo服务发布为镜像为例,示例见附件2:FROM registry.xcompany./java:openjdk-7-jreMAINTAINER zhangsanENV spring.profiles.active=productionENV JAVA

13、_OPTS=-Xmx1024mRUN mkdir -p /appCOPY target/subproject1.war /app/COPY ./startup.sh /app/RUN chmod +x /app/startup.shWORKDIR /appCMD ./startup.shEXPOSE 8080c) Makefile文件: 包括编译项目、将项目打包成Docker镜像、将镜像Push到镜像仓库、在K8s上创建ReplicationController、在K8s上创建service的命令脚本:IMAGE_PREFIX = registry.xcompany./project1/COM

14、PONENT = subproject1ifndef BUILD_TAG BUILD_TAG = latestendifIMAGE = $(IMAGE_PREFIX)$(COMPONENT):$(BUILD_TAG)ifndef KUBE_OPS KUBE_OPS = -server= s:/api.devproject. -namespace=project1endifclean:mvn cleancompile: cleanmvn -U -DskipTests=true -Dmaven.javadoc.skip=true package#将当前程序打包成Docker镜像build:dock

15、er build -t $(IMAGE) .#将当前镜像Push到镜像仓库push:docker push $(IMAGE)run:docker run -rm -it -e spring.profiles.active=application -p 8080:8080 $(IMAGE)#部署RelicationControllerdeploy:kubectl create -f kube-rc.yaml $(KUBE_OPS)redeploy:kubectl replace -f kube-rc.yaml $(KUBE_OPS)undeploy:kubectl delete -f kube-rc.yaml $(KUBE_OPS)#创建servicedeploy-svc:kubectl create -f kube-svc.yaml $(KUBE_OPS)undeploy-svc:kubectl delete -f kube-svc.yaml $(KUBE_OPS)d) K8s部署配置文件,创建

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1