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

  软件开发行业,经过一个或多个项目之后,企业都会沉淀出许多非常优秀的组件,这些优秀的组件能够为今后其他的项目提供便利的基础。总体而言,企业的沉淀的组件大致可分为三类:程序类组件、数据类组件、配置类组件。

程序类组件:程序类组件是最常见的组件,包括常见的java、go、python等代码,经过构建之后,用于可独立部署或使用的介质,如:日志工具类、日期工具类、字符串工具类、邮件发送工具类等;

数据类组件:在应用的变更过程中,一般都会涉及到数据库的变更,包括数据库的备份与恢复,数据表的备份与恢复,以及按照要求进行数据变更,如:表空间检查与清理,数据的备份与恢复等;

配置类组件:传统的应用配置信息主要以xml、config或properties文件为主,且应用和配置打包成一个部署包,而应用与配置聚合在一起,必然导致不同的环境,需要重新构建打包,然微服务体系下,应用与配置分离,因此专门存储配置的程序,称为配置类组件,如:apollo、zookeeper等。

1. 组件定义规范

组件的分类主要有程序类组件、数据类组件和配置类组件,因此,组件的定义也应该从程序类组件规范、数据类组件规范、配置类组件规范。

(一)     程序类组件规范

1)   命名规范:公司域名.工程名.版本.介质后缀,举例说明:com.primeton.common-util.1.1.3.jar,其中

a)   com.primeton为公司域名;

b)   common-util为工程名;

c)   1.1.3为版本号;

d)   jar为介质后缀。

2)   包名规范:公司域名.模块名称,举例说明:com.primeton.common.util;

3)   类名规范,例如:StringUtil,DateUtil等;

(二)     数据类组件规范

1)   开发规范:数据类组件开发过程中,需要将数据类相关的参数进行抽象,以便于其他项目或产品进行复用,例如:实例名、用户名密码、端口等。

2)   命名规范:数据类组件一般为脚本组件,因此在脚本命名方面,需要能够体现出场景含义,如:checkTablespace,backupDB等;

(三)     配置类组件规范

配置类组件一般是将程序中的配置文件进行提取并存储,如:Apollo、Spring Config等。

2. 组件使用规范

组件创建后,如何在实际应用中使用,其实需要遵循一定的使用原则或使用规范,具体如下:

(一)     在应用使用过程中,仅添加本应用需要的版本,禁止添加同一组件多个版本;

(二)     在应用使用过程中,原则上只能添加Release版本,不建议添加Snapshop版本;

(三)     在应用使用过程中,需要注意组件支持的环境版本,如:JDK8、DB2 9.7等;

(四)     在应用使用过程中,需要注意是否有必要使用某组件,如:进行数据库迁移时,是否有必要使用配置类组件。

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

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

微服务架构下组件管理规范的相关文章

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

传统的介质管理,主要是以jar.war为主,但是随着微服务的畅行及容器技术的成熟,介质的管理不仅包括jar.war而且包括zip.tar.bin等各种各样的安装包及构建包,随着这些介质类型的丰富,数量的增多,如何进行管控介质,则显得非常重要.微服务体系下,介质的管理,主要从介质的规范.介质的存储以及介质的使用方面进行规范化. 1. 介质构建规范 微服务体系下介质的种类及数量异常庞大,如果仅采用手工构建完全不仅效率上存在一定问题,而且质量方面也存在一定的问题.因此,在介质构建方面规范如下: 构建工

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

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

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

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

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

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

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

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

微服务架构下分布式事务解决方案——阿里云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 微服务落地存在的问题

微服务架构下的身份认证

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

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

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