#!/bin/bash -eIMAGE=registry.xcompay.com/project1/sub-project1:$IMAGE_VERSIONmake compileif [ $build = "true" ]; then   echo "docker build -t $IMAGE"   docker build -t $IMAGE .   echo "docker push $IMAGE"   docker push $IMAGEfiif [ $undeploy = "true" ]; thenmake undeployfiif [ $deploy = "true" ]; thenmake deployfiif [ $deploysvc = "true" ]; thenmake deploy-svcfi

具体的过程说如下：

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代劳指向web server的地址，即可在本地调试与动态Web端的交互。

b) WEB层与办事层联调、办事层之间联调、办事层与基本层联调，分为两种方法：

本地调试：安排一个专用的zookeeper注册中间，开辟者可以把本机地址注册到注册中间，供相干人员临时调用办事调试。

集成情况捣言：提交卸码触发Jenkins义务，将办事打包成容器镜像，安排到K8s娠在完全的体系运行情况中浇忧Ⅶ试。具体的集成情况编排依附于k8s完成。

微办事的分层和办事交互设计

关于微服架构的利弊以及设计原则有很多有名的文┞仿有介绍，例如MarinFowler的博文《Microservices:a definition of this new architectural term》和来自DZone community社区的《Microservices in Practice: From Architecture to Deployment》在InfoQ等技巧网站都有中文翻译，本文就纰谬概念和设计原则做过多赘述。本末节主如果解释关于项目标逻辑分层构造和办事交互方面的设计。

本项目遵守以下微办事架构的重要基来源基本则，然则也会根据具体项目情况有所保存。

i. 单一义务原则（Single Responsibility Principle，SRP）

ii. 包管微办事设计能支撑办事的敏捷/自力地开辟和安排。

架构分层设计

i. 大年夜Git上拉代替码，编译、宣布项目；

如图2所示，项目标架构是分为四层：静态UI层、动态WEB层、营业办事层、基本营业层。

i. 静态UI层，直接面向用户的操作展示界面，包含静态UI设计和JS交互代码，重要采取Angulars框架；

ii.动态WEB层是各营业办事的“门面”，根据前端设计的须要调用、组装营业办事层的API，相对来说，这一层更改的频率较高，例如体系须要进行流程优化或者前端UE改革，响应的都要变革这一层。动态WEB层采取Java Spring或者python Django框架实现；

iii.营业办事层，根据营业需求按照功能对基本办事层进行扩大和包装，采取Dubbo分布式办事框架实现，具体版本是当当扩大过的Dubbox，支撑REST API，并且对Spring的支撑进级到了3.x；

iv. 基本办事层比较稳定，供给一些基本功能，采取Go说话/Ruby/Java/Python等多种说话实现的。

各层之间的交互通信设计

i. 各层次之间以及同一层次之间的交互主如果按照微办事架构的设计原则，采取轻量式通信机制：REST API、Dubbo API（hessian协定）和异步消息实现的。

ii.然则也有些办事之间的交互是经由过程共享数据库实现的，这一点是违背微办事架构强调的“自力的办事、自力的数据库”的原则的。本项目每个办事尽可能应用自力的数据表，然则采取了共享的数据库。根据具体营业场景，综合推敲技巧成本、以及耦合带来的风险大年夜小等身分，部分不合层次的办事之间的交互是经由过程数据表实现的。这也是大年夜单体式应用进化到分布式应用的一个折中筹划，将来若体系范围扩大年夜，要拆分数据库价值并不会很大年夜。然则弗成否定，微办事架构下应用共享的数据库是存在风险的，将来可能因为某些蹩脚的设计使得微办事之间的耦合性变大年夜，导致微办事不再“微”了。

【编辑推荐】

1. 一个更好的可视化微办事架构的方法
2. App 组件化/模块化之路——构建开辟架构思路
3. 实施微办事架构的关键技巧
4. 【深刻浅出jQuery】源码浅析--整体架构
5. 移动开辟架构之MVVM模式

　　推荐阅读

　　移动开发架构之MVVM模式

【技巧沙龙】AI开辟者拭魅战营-7分钟打造1个定制技能。7月22号，我们等你一路！ MVVM概念的提出和来源【编辑推荐】 17个晋升iOS开辟效力的必用对象 iOS开辟－基本框架 小白若何>>>详细阅读

本文标题：微服务架构下的开发部署

地址：http://www.17bianji.com/lsqh/36253.html

 1/2    1