微服务架构的部署Word文档格式.docx

上传人:b****6 文档编号:8657391 上传时间:2023-05-12 格式:DOCX 页数:10 大小:475.45KB
下载 相关 举报
微服务架构的部署Word文档格式.docx_第1页
第1页 / 共10页
微服务架构的部署Word文档格式.docx_第2页
第2页 / 共10页
微服务架构的部署Word文档格式.docx_第3页
第3页 / 共10页
微服务架构的部署Word文档格式.docx_第4页
第4页 / 共10页
微服务架构的部署Word文档格式.docx_第5页
第5页 / 共10页
微服务架构的部署Word文档格式.docx_第6页
第6页 / 共10页
微服务架构的部署Word文档格式.docx_第7页
第7页 / 共10页
微服务架构的部署Word文档格式.docx_第8页
第8页 / 共10页
微服务架构的部署Word文档格式.docx_第9页
第9页 / 共10页
微服务架构的部署Word文档格式.docx_第10页
第10页 / 共10页
亲,该文档总共10页,全部预览完了,如果喜欢就下载吧!
下载资源
资源描述

微服务架构的部署Word文档格式.docx

《微服务架构的部署Word文档格式.docx》由会员分享,可在线阅读,更多相关《微服务架构的部署Word文档格式.docx(10页珍藏版)》请在冰点文库上搜索。

微服务架构的部署Word文档格式.docx

快速的部署发布离不开老牌持续集成明星Jenkins,本项目通过Jenkins任务构建代码、将应用打包成Docker镜像,最终发布到K8s环境中将容器运行起来。

Shell脚本:

编写Shell脚本将项目打分支、发布应用等开发阶段的配置管理工作自动化,降低运维门槛、提高配置管理和运维的效率。

WIKI:

Gitlib上的WIKI功能相对简陋,因此项目组选择dokuwiki作为异地团队协作和沟通的工具,团队成员可以将设计文档、知识分享文档、公告信息等信息可以更新到wiki上,便与协同开发。

禅道:

为了便于开发计划、开发任务和bug关联起来,本项目使用禅道进行开发任务和bug管理。

人员分工及开发流程

微服务架构应用的开发、部署的复杂度都是远大于单体式应用的,靠运维人员手工的配置管理显然是难于应付了。

DevOps主张以自动化任务处理方式实现软件交付及基础设施更新,可以说是微服务架构应用开发和运维的必要条件,本项目采用DevOps的理念的开发流程进行开发。

实现部署和运维的自动化需要工具,同时DevOps强调软件开发者与其他IT职工及管理层间的协作与沟通,因此明确的人员分工和开发流程是与工具同样重要的因素。

通俗的说,就是有了工具,大家要知道怎么使用工具,并且愿意使用工具才能真正到达提高研发效率的目的。

项目组的主要工作成员无非也是做开发、测试和系统管理三类工作,这里只说明与传统的企业应用开发过程中三类人员所做的工作略有不同的工作内容。

开发人员:

a)开发者做开发设计,需要将涉及到接口部分设计更新到wiki上,供调用者评审和调用。

b)开发者除了编写程序逻辑外,还需要注意编写单元测试用例,因为分布式应用联调相对复杂,先做在编写单服务时做好了测试再联调能够提高开发效率。

c)由于本项目是采用Docker容器作为发布载体的,开发者可能需要修改DockerFile模板里的部分参数,便于部署阶段能将编译后的代码打包到镜像中。

相对于传统的开发方式,这是对开发者额外的要求。

让所有开发者懂Dockerfile似乎要求也有点高,其实每个子项目中的DockerFile及脚本一般是在搭建项目框架时,主要系统配置管理员编写的好的模板,假设开发人员不懂相关技术,也可以跟配置管理员沟通需求,由配置管理员修改相关文件。

测试人员:

测试人员的工作没有什么特别,只是需要注意除了每个Sprint阶段的测试外,还需要配合开发人员持续集成的测试;

系统配置管理人员:

一般DevOps的开发方式是依赖于云基础平台以及自动化发布工具的,因此相对于传统开发方式,对系统配置管理者的技术要求会比较低。

但是,我们的项目开发目的就是构建一个能支撑DevOps流程的平台,其开发本身还不具备相应的平台基础。

因此,我们项目最初的系统配置管理工作是由架构师来做的,主要需要做如下这些事:

a)部署运行项目组开发需要用到公共的服务组件、例如zookeeper注册中心、DockerRegistry镜像仓库、数据库等;

b)为子项目编写在git上打分支的脚本,便于测试发版的时候打分支;

c)编写各类型应用发布部署成镜像的Dockerfile;

d)制作或者在网上找到现成的开发所需环境的Docker镜像,并且Push到项目开发使用的私有镜像库中;

e)编写Shell脚本实现将子项目打包成Docker镜像,并且Push到镜像仓库中。

f)在Jenkins上配置自动编译或者部署任务,实现持续集成和部署。

本文将对项目的开发、部署联调以及测试发版流程和标准做简要说明,并提供项目各个阶段使用到的部分自动化脚本工具例如。

图1项目持续集成和部署流程

代码分支管理:

如下图,在git上创建的每一个项目都需要至少建立develop和master两个分支。

开发人员只有权限把代码提交到develop分支上,平时的持续集成和联调都从develop分支上获取代码。

每个Sprint阶段测试发版时,配置管理员从develop分支上创建一个用于测试的release分支。

当测试修改bug时,开发人员只把修改后的代码提交到对应的测试Release分支上。

当测试版本稳定后,由配置管理员将代码合并到Master分支中。

自动部署和发布:

项目借助于Shell脚本、Dockerfile、K8s配置文件和Jenkins任务实现了自动化的持续集成和部署。

配置管理员在项目目录下编写的脚本文件结构如图2所示。

a)创建分支的shell脚本,例如见附件1;

#!

/bin/bash

if[-z"

$1"

];

then

cat<

<

EOF

Usage:

branch-release.sh<

version>

exit1

fi

DEPLOY_VERSION=$1

RP_FILES=(subproject1/kube-rc.yamlsubproject1/pom.xmlsubproject1/Makefile)

if[-z$(gitbranch-a|grep-e/${DEPLOY_VERSION}$)];

then 

gitbranch${DEPLOY_VERSION}

gitcheckout${DEPLOY_VERSION}

else

gitpull

#替换k8s配置文件中环境指向,从开发切换到测试

#替换掉pom.xml文件中的SNAPSHOT为release版本号

#替换掉makefile中发布的镜像Tag的latest为release版本号

forfin${RP_FILES[@]};

do

sed-i-e"

s#api.devproject#api.testproject#g"

\

-e"

s#<

0.0.1-SNAPSHOT<

/version>

#<

${DEPLOY_VERSION}-SNAPSHOT<

#g"

s#latest#${DEPLOY_VERSION}#g"

$f

done

gitcommit-a-m"

CreateBranch${DEPLOY_VERSION}"

gitpushorigin${DEPLOY_VERSION}

b)Dockerfile例如文件,将Javadubbo服务发布为镜像为例,例如见附件2:

FROMregistry.xcompany/java:

openjdk-7-jre

MAINTAINERzhangsan

ENVspring.profiles.active="

production"

ENVJAVA_OPTS="

-Xmx1024m"

RUNmkdir-p/app 

COPYtarget/subproject1.war/app/

COPY./startup.sh/app/

RUNchmod+x/app/startup.sh

WORKDIR/app

CMD["

./startup.sh"

]

EXPOSE8080

c)Makefile文件:

包括编译项目、将项目打包成Docker镜像、将镜像Push到镜像仓库、在K8s上创建ReplicationController、在K8s上创建service的命令脚本:

IMAGE_PREFIX=registry.xcompany/project1/

COMPONENT=subproject1

ifndefBUILD_TAG

BUILD_TAG=latest

endif

IMAGE=$(IMAGE_PREFIX)$(COMPONENT):

$(BUILD_TAG)

ifndefKUBE_OPS

KUBE_OPS=--server=s:

//api.devproject--namespace=project1

clean:

mvnclean

compile:

clean

mvn-U-DskipTests=true-Dmaven.javadoc.skip=truepackage

#将当前程序打包成Docker镜像

build:

 

dockerbuild-t$(IMAGE).

#将当前镜像Push到镜像仓库

push:

dockerpush$(IMAGE)

run:

dockerrun--rm-it-espring.profiles.active=application-p8080:

8080$(IMAGE)

#部署RelicationController

deploy:

kubectlcreate-fkube-rc.yaml$(KUBE_OPS)

redeploy:

kubectlreplace-fkube-rc.yaml$(KUBE_OPS)

undeploy:

kubectldelete-fkube-rc.yaml$(KUBE_OPS)

#创建service

deploy-svc:

kubectlcreate-fkube-svc.yaml$(KUBE_OPS)

undeploy-svc:

kubectldelete-fkube-svc.yaml$(KUBE_OPS)

d)K8s部署配置文件,创建ReplicationController、创建service例如见附件4:

#创建ReplicationController

apiVersion:

v1

kind:

ReplicationController

metadata:

name:

subproject1

spec:

replicas:

1

selector:

template:

metadata:

labels:

spec:

containers:

-name:

image:

registry.xcompany/project1/subproject1:

latest

imagePullPolicy:

Always

env:

DUBBO_REGISTRY_ADDRESS

value:

"

kube:

//zookeeper:

2181"

DUBBO_REGISTRY_REGISTER

true"

ports:

-containerPort:

8888

#创建Service

Service

component:

-port:

nodePort:

16888

svc-subproject1

type:

NodePor

e)配置管理员在Jenkins上配置自动或手动触发的任务,在jenkins任务中配置shell脚本,可实现应用的一键部署,例如见附件5。

/bin/bash-e

IMAGE=registry.xcompay/project1/sub-project1:

$IMAGE_VERSION

makecompile

if[$build="

echo"

dockerbuild-t$IMAGE"

dockerbuild-t$IMAGE.

dockerpush$IMAGE"

dockerpush$IMAGE

if[$undeploy="

makeundeploy

if[$deploy="

makedeploy

if[$deploysvc="

makedeploy-svc

具体的过程说如下:

i.从Git上拉取代码,编译、发布项目;

ii.将编译好的程序包,打包成Docker镜像;

iii.将打包好的Docker镜像Push到镜像仓库;

iv.Jenkins执行Shell脚本命令,从镜像仓库拉取镜像在K8s环境中创建pod和RC,将应用程序及其运行环境所在的容器在K8s平台上运行起来。

测试与发版:

从图中可以看到,项目的开发环境和测试环境是相互隔离的两套环境。

a)部署在开发环境的应用代码,来自develop分支,对应的Docker镜像Tag用latest,供开发人员调试、以及测试人员随时协助做集成测试;

b)部署在测是环境的应用代码,来自每到一个Sprint阶段发版测试时配置管理员从develop分支中打出的测试发版分支,分支名对应的版本号不同,相应的Docker镜像的tag也会随是版本号改变。

测试环境中部署的应用主要用于测试验证。

部署联调:

项目分为四层:

前端UI、WEB层有假设干个web应用、Service层包括假设干个分布式服务、基础底层。

这里简要说明一下各层之间的调试方式:

a)前端和Web层联调:

前端开发人员本地启动一个Nginx,配置nginx.conf文件将localhost代理指向webserver的地址,即可在本地调试与动态Web端的交互。

b)WEB层与服务层联调、服务层之间联调、服务层与基础层联调,分为两种方式:

本地调试:

部署一个专用的zookeeper注册中心,开发者可以把本机地址注册到注册中心,供相关人员临时调用服务调试。

集成环境调试:

提交代码触发Jenkins任务,将服务打包成容器镜像,部署到K8s上在完整的系统运行环境中联合调试。

具体的集成环境编排依赖于k8s完成。

微服务的分层和服务交互设计

关于微服架构的利弊以及设计原则有很多著名的文章有介绍,例如MarinFowler的博文《Microservices:

adefinitionofthisnewarchitecturalterm》和来自DZonecommunity社区的《MicroservicesinPractice:

FromArchitecturetoDeployment》在InfoQ等技术网站都有中文翻译,本文就不对概念和设计原则做过多赘述。

本小节主要是说明关于项目的逻辑分层结构和服务交互方面的设计。

本项目遵守以下微服务架构的主要基本原则,但是也会根据具体项目情况有所保留。

i.单一责任原则〔SingleResponsibilityPrinciple,SRP〕

ii.保证微服务设计能支持服务的敏捷/独立地开发和部署。

图2分层结构及通信机制

架构分层设计

如图2所示,项目的架构是分为四层:

静态UI层、动态WEB层、业务服务层、基础业务层。

i.静态UI层,直接面向用户的操作展示界面,包括静态UI设计和JS交互代码,主要采用Angulars框架;

ii.动态WEB层是各业务服务的“门面”,根据前端设计的需要调用、组装业务服务层的API,相对来说,这一层变动的频率较高,例如系统需要进行流程优化或者前端UE改造,相应的都要变更这一层。

动态WEB层采用JavaSpring或者pythonDjango框架实现;

iii.业务服务层,根据业务需求按照功能对基础服务层进行扩展和包装,采用Dubbo分布式服务框架实现,具体版本是当当扩展过的Dubbox,支持RESTAPI,并且对Spring的支持升级到了3.x;

iv.基础服务层比较稳定,提供一些基础功能,采用Go语言/Ruby/Java/Python等多种语言实现的。

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 工程科技 > 电子电路

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2