微服务架构下介质管理规范

  传统的介质管理,主要是以jar、war为主,但是随着微服务的畅行及容器技术的成熟,介质的管理不仅包括jar、war而且包括zip、tar、bin等各种各样的安装包及构建包,随着这些介质类型的丰富,数量的增多,如何进行管控介质,则显得非常重要。微服务体系下,介质的管理,主要从介质的规范、介质的存储以及介质的使用方面进行规范化。

1. 介质构建规范

  微服务体系下介质的种类及数量异常庞大,如果仅采用手工构建完全不仅效率上存在一定问题,而且质量方面也存在一定的问题。因此,在介质构建方面规范如下:

  构建工具:采用市场上的成熟产品进行构建,例如:maven、ant、grade、npm以及DockerFile进行构建。

  版本信息:建议采用四阶段进行命名版本,例如:V1.2.1_180806R,版本说明:V1为主版本号,2为子版本号,1位修正版本号,180806R为编译版本号。其中:

字母V为固定编号;

    主版本号,初始编号为1,当有重大升级或变更时,编号+1;

    子版本号,初始编号为0,应用有新功能或需求上线时,子版本号+1,若主版本号发生变更时,子版本号自动归零;

    修正版本号,初始编号为0,当无新功能上线,仅修改bug时,修正版本号+1,主版本或子版本号发生变更时,修正版本号自动归零;

    编译版本号,6位数字+字母R或B,其中R表示Release,B表示Build,6位数字为当前日期yyMMdd,R和B一般对应测试版本和正式投产版本。

1.1.1.2. 介质存储规范

  介质的存储,一般建议采用Nexus进行存储,在存储方面,建议对存储介质进行分类,分为开发库、测试库、投产库,原则上开发库建议实现每日构建存储,并保留近期的5~10个版本即可,测试库是通过开发验证后,用于部署测试环境的版本库,而生产库则用于部署准生产环境或生产环境用的库。

  在企业内,一般nexus为公共介质存储仓库,因此,在介质仓库的分类方面,因遵循以下规范:

  公共介质仓库组:XXX-repo-public(maven2(group)类型);

  公共介质release仓库:XXX-repo-release(maven2(hosts)类型);

  公共介质snapshot仓库:XXX-repo-snapshot (maven2(hosts)类型);

  将共介质releases仓库和公共介质snapshot仓库加入到公共介质仓库组;

  私有介质releases仓库:XXX-repo-releases (maven2(hosts)类型);

  私有介质snapshot仓库:XXX-repo-snapshot (maven2(hosts)类型);

    其中:XXX为企业/公司英文简称缩写;

1.1.1.3. 介质使用规范

  微服务体系下,系统介质的使用,主要有以下几个方面建议:

   应用的构建,依赖的介质,建议从介质库中进行拉取,而非采用手动进行复制粘贴方式;

   应用的部署,需要的介质,建议从介质库中进行拉取,而非采用本地缓存文件部署;

原文地址:https://www.cnblogs.com/pengteng/p/10888930.html

时间: 2024-10-11 22:12:49

微服务架构下介质管理规范的相关文章

微服务架构下组件管理规范

软件开发行业,经过一个或多个项目之后,企业都会沉淀出许多非常优秀的组件,这些优秀的组件能够为今后其他的项目提供便利的基础.总体而言,企业的沉淀的组件大致可分为三类:程序类组件.数据类组件.配置类组件. 程序类组件:程序类组件是最常见的组件,包括常见的java.go.python等代码,经过构建之后,用于可独立部署或使用的介质,如:日志工具类.日期工具类.字符串工具类.邮件发送工具类等: 数据类组件:在应用的变更过程中,一般都会涉及到数据库的变更,包括数据库的备份与恢复,数据表的备份与恢复,以及按

Re:从 0 开始的微服务架构--(四)如何保障微服务架构下的数据一致性--转

原文地址:http://mp.weixin.qq.com/s/eXvoJew3bjFKzLLJpS0Otg 随着微服务架构的推广,越来越多的公司采用微服务架构来构建自己的业务平台.就像前边的文章说的,微服务架构为业务开发带来了诸多好处的同时,例如单一职责.独立开发部署.功能复用和系统容错等等,也带来一些问题. 例如上手难度变大,运维变得更复杂,模块之间的依赖关系更复杂,数据一致性难以保证,等等.但是办法总是比问题多,本篇文章就来介绍一下我们是如何保障微服务架构的数据一致性的. 微服务架构的数据一

从 0 开始的微服务架构:(四)如何保障微服务架构下的数据一致性

虽然已经红了很久,但是"微服务架构"正变得越来越重要,也将继续火下去.各个公司与技术人员都在分享微服务架构的相关知识与实践经验,但我们发现,目前网上的这些相关文章中,要么上来就是很有借鉴意义的干货,要么就是以高端的专业术语来讲述何为微服务架构.就是没有一个做到成熟地将技术传播出来,同时完美地照顾"初入微服务领域人员",从 0 开始,采用通俗易懂的语言去讲解微服务架构的系列.所以,我们邀请青柳云的苏槐与 InfoQ 一起共建微服务架构专题"Re:从 0 开始

如何保障微服务架构下的数据一致性

1.微服务架构的数据一致性问题 以电商平台为例,当用户下单并支付后,系统需要修改订单的状态并且增加用户积分.由于系统采用的是微服务架构,分离出了支付服务.订单服务和积分服务,每个服务都有独立数据库做数据存储.当用户支付成功后,无论是修改订单状态失败还是增加积分失败,都会造成数据的不一致. 为了解决例子中的数据一致性问题,一个最直接的办法就是考虑数据的强一致性.那么如何保证数据的强一致性呢?我们从关系型数据库的 ACID 理论说起. 关系型数据库具有解决复杂事务场景的能力,关系型数据库的事务满足

微服务架构下分布式事务解决方案——阿里云GTS

https://blog.csdn.net/jiangyu_gts/article/details/79470240 1 微服务的发展 微服务倡导将复杂的单体应用拆分为若干个功能简单.松耦合的服务,这样可以降低开发难度.增强扩展性.便于敏捷开发.当前被越来越多的开发者推崇,很多互联网行业巨头.开源社区等都开始了微服务的讨论和实践.Hailo有160个不同服务构成,NetFlix有大约600个服务.国内方面,阿里巴巴.腾讯.360.京东.58同城等很多互联网公司都进行了微服务化实践.当前微服务的开

微服务架构下分布式事务方案

1 微服务的发展 微服务倡导将复杂的单体应用拆分为若干个功能简单.松耦合的服务,这样可以降低开发难度.增强扩展性.便于敏捷开发.当前被越来越多的开发者推崇,很多互联网行业巨头.开源社区等都开始了微服务的讨论和实践.Hailo有160个不同服务构成,NetFlix有大约600个服务.国内方面,阿里巴巴.腾讯.360.京东.58同城等很多互联网公司都进行了微服务化实践.当前微服务的开发框架也非常多,比较著名的有Dubbo.SpringCloud.thrift .grpc等. 2 微服务落地存在的问题

微服务架构下的数据一致性:概念及相关模式

主页:http://www.howardliu.cn/ 博客:微服务架构下的数据一致性:概念及相关模式 从2014年开始,微服务逐渐进入大家的实现,被认为是下一代实现信息化的有效手段.设计到系统,其中绕不开的就是数据一致性,从本地事务,到后来的分布式事务,都能够有效的保证数据一致性.但是在微服务架构中,这两种方式都不是最好的选择. 1. 使用本地事务和分布式事务保证一致性 在传统的单击应用中,最简单.最直接.最普遍的会使用一个关系型数据库,通过关系型数据库的事务保证数据的一致性.这种事务有四个基

微服务架构下的身份认证

从单体应用架构到分布式应用架构再到微服务架构,应用的安全访问在不断的经受考验.为了适应架构的变化.需求的变化,身份认证与鉴权方案也在不断的变革.面对数十个甚至上百个微服务之间的调用,如何保证高效安全的身份认证?面对外部的服务访问,该如何提供细粒度的鉴权方案?本文将会为大家阐述微服务架构下的安全认证与鉴权方案. 单体应用 VS 微服务 随着微服务架构的兴起,传统的单体应用场景下的身份认证和鉴权面临的挑战越来越大.单体应用体系下,应用是一个整体,一般针对所有的请求都会进行权限校验.请求一般会通过一个

微服务架构下业务单机QPS跑不上去应从哪些角度分析

这是做应用运维老生常谈的一个事儿,经常做,今天把他总结一下. 不管什么性质的业务,吞吐量的本质是木桶原理,能跑多大量取决于木桶最短的那个板,脑袋里是不是立刻可以出现木桶的那个模型,哈哈!!换句话说,当有能力提高短板的高度时,业务的吞吐量就会有所上升,但同样有个边际效应,经过多次的优化后,当再次提高短板的成本非常非常大,而付出后提高的量很低时,那就不要较劲了,直接加服务器吧. 言归正传,先解释一下单机QPS跑不上去的现象,具体表现就是高过一个点后错误率增加.时延增大,很显然遇到短板了,那么这个短板