微服务架构下规范

已于 2022-05-18 15:14:36 修改
阅读量113 收藏
点赞数
分类专栏： java 程序人生 架构 文章标签： 架构 java 开发语言
于 2022-05-18 15:14:26 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/x275920/article/details/124843121
版权
程序人生 同时被 3 个专栏收录
709 篇文章 1 订阅
订阅专栏
java
669 篇文章 13 订阅
订阅专栏
架构
479 篇文章 11 订阅
订阅专栏

不以规矩，不能成方圆

应用与组件拆分，一组件一仓库

Maven安全规范

分支策略

研发协同平台

研发变更流程

开放的，任务可插拨pipeline

今天先到这儿，希望对云原生，技术领导力， 企业管理，系统架构设计与评估，团队管理, 项目管理, 产品管管，团队建设 有参考作用

                     资源获取：

大家点赞、收藏、关注、评论啦 、查看👇🏻👇🏻👇🏻微信公众号获取联系方式👇🏻👇🏻👇🏻

 精彩专栏推荐订阅：在下方专栏👇🏻👇🏻👇🏻👇🏻

每天学四小时：Java+Spring+JVM+分布式高并发，架构师指日可待

我有一头小花驴
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
微服务接口定义规范
11-09
微服务接口设计采用Restful风格的接口规范，下面是基于Restful风格要求制订的接口设计规范
微服务系统设计规范
jiabin0929的专栏
03-24 560
基础数据禁止多处维护，以基础服务提供查询接口的形式访问基础数据，如果对性能考虑需要做数据冗余，前提是对该冗余数据只读，并对时效性及重要度要求不高，然后通过异步消息的形式同步该冗余数据。A、下层服务不能调用上层服务，如果有下层服务需要访问上层服务的需求，可以考虑调整架构。在需求不明确的情况下，不做超前设计，架构设计始终是结合业务需求而设计的，需求不明确的情况下，超前设计可能会造成返工。非必要情况下，尽量不做系统拆分，拆分必然会造成结构更复杂，维护、管理、部署更繁琐，而且需要依赖微服务组件。
微服务架构设计规范
tangyb828的博客
05-27 3344
一、项目系统服务约定 1、项目工作空间（项目集） 项目工作空间系统源码根目录，一般以项目名称做为工作空间，例如：iToken 注：项目按前后端分离设置，项目工作空间可以进一步划分，后端项目工作空间以项目名称，前端项目工作空间以项目名称-web。 示例： iToken：项目工作空间 |__itoken：后端项目工作空间 |__itoken-web：前端项目工作空间 2、后端项目服务规划 2.1、服务命名 xx-xx/xx-xx-xx 项目名-模块名／项目名-模块名-二级模块名 大小写：全部小写，单词间
微服务开发规范
07-16 410
开发规范 环境约定 debug: 无依赖（mock），本地联调（前端），单元测试 dev: 有依赖，服务端联调，集成测试 sit: 功能测试 pre：上线前测试，演练，模拟上线 prd：生产环境 版本号 通用约定 版本号的格式为 A.B.C (又称 Major.Minor.Patch)，递增的规则为： A 表示主版本号，当 API 的兼容性变化时，A 需递增。 B 表示次版本号，当增加功能时(不影响 API 的兼容性)，B 需递增。 C 表示修订号，当做 Bug 修复时(不影响 API 的兼容性)
微服务架构原则
qq_39126966的博客
02-21 590
围绕DDD的领域概念定义，并将技术架构和所依赖的其他组件封装到限界上下文中，构建了高度解耦的架构。每个服务包含其限界上下文的所有部分，并通过消息（例如REST或消息队列） 和其他限界上下文进行通信。因此，服务不需要知道另一个服务的实现细节（例如数据库模式），从而避免了不当的耦合。该架构的运作目标是用一个服务取待另一个服务而不影响其他服务。 微服务架构通常遵循以下七个原则： 1、围绕业务领域建模 微服务设计的重点是基于业务领域，而不是基于技术架构。因此，架构量子反映了限界上下文。一些开发...
转型微服务架构完整实施方案
01-27
对于企业从传统IT架构到微服务架构的转型，绝对不是盲目的跟风互联网企业，而是企业的业务规范，企业的信息化水平和IT成熟度发展到一定阶段后的比如诉求，那么这些关键的诉求究竟有哪些？首先可以看到当企业的信息化...
基于Spring Boot和Spring Cloud的微服务架构设计源码
最新发布
04-03
本设计源码提供了一个基于Spring Boot和Spring Cloud的微服务架构。项目包含399个文件，主要使用Java、Shell和HTML编程语言。文件类型包括223个Java源代码文件、48个XML配置文件、36个YAML配置文件、35个PNG图片文件...
听听八年阿里架构师怎样讲述Dubbo和SpringCloud微服务架构
02-24
虽然微服务架构没有公认的技术标准和规范或者草案，但业界已经有一些很有影响力的开源微服务架构框架提供了微服务的关键思路，例如Dubbo和SpringCloud。各大互联网公司也有自研的微服务框架，但其模式都于这二者相差...
微服务上线规范
zhanglehes的专栏
07-15 514
上线规范的作用时尽可能避免（减少）因线上变动造成的事故。主要分为上线前、上线中和上线后的注意事项。
微服务架构下组件管理规范
weixin_30480075的博客
05-18 554
　　软件开发行业，经过一个或多个项目之后，企业都会沉淀出许多非常优秀的组件，这些优秀的组件能够为今后其他的项目提供便利的基础。总体而言，企业的沉淀的组件大致可分为三类：程序类组件、数据类组件、配置类组件。 程序类组件：程序类组件是最常见的组件，包括常见的java、go、python等代码，经过构建之后，用于可独立部署或使用的介质，如：日志工具类、日期工具类、字符串工具类、邮件发送工具类等； 数...
微服务拆分规范
justlpf的专栏
06-17 385
将。系统中的单个微服务可以被独立部署和扩展，且各个微服务之间是高内聚、松耦合的。微服务之间采用通信机制暴露接来实现通信。那么微服务可以怎么拆分呢？
微服务架构实战-1-项目开发规范
Pursuit_li的博客
02-01 276
编码和命名规范
微服务项目规范(一)
dd10850的博客
04-19 818
以下规范仅代表个人观点以及部分公司的规范，不一定适用于所有项目，具体如何准守以实际项目而定。 一.模型篇 请求入参 所有Controller入参,一律使用 DTO结尾进行交互 所有 DTO 命名,前面采用驼峰命名,后面DTO大写 所有DTO内参数,如果是一组,请用List<类型>进行接口,尽量不用分隔符隔开,然后字符串接收, 所有DTO放置在子模块Model...
讲解通俗易懂的微服务架构
私信可回答各种问题~
05-21 1124
讲解通俗易懂的微服务架构，分别对微服务的架构，体系作进一步描述。
微服务开发模式系列之(四)：微服务SLA规范
微服务技术与实践专栏
06-04 1726
更多信息，请参考：https://www.huaweicloud.com/product/cse.html
微服务设计规范总结
myroncham的博客
01-15 2855
一、微服务设计原则 高内聚低耦合、职责单一：每个微服务模块职责单一独立，负责各自业务功能。微服务之间尽量减少调用，做到高内聚低耦合。 前后端分离：将前端和后端代码进行分离，包括开发分离，部署分离，代码存放分离。前端负责页面展示，后端负责业务数据处理。前端通过HTTP协议或者其他协议进行交互。 围绕业务拆分：微服务应该围绕业务进行拆分，每个微服务聚焦于一个特定的业务功能，在技术选型上比较灵活，不局限于某个固定的技术栈。 日志与监控：随着微服务系统不断升级演进，微服务数量剧增，系统出现故障的几率也在增大
《SpringCloud Alibaba 微服务架构》专题(一)-Spring Cloud Alibaba初识
02-09 384
目录1.Spring Cloud Alibaba简介1.1.先说说 Spring Cloud1.2.Spring Cloud Alibaba2.主要功能3.主要组件4.如何构建5.如何使用6.版本管理规范7.参考文档8.小结 1.Spring Cloud Alibaba简介 Spring Cloud Alibaba 是阿里巴巴提供的微服务开发一站式解决方案，是阿里巴巴开源中间件与 Spring Cloud 体系的融合。 马老师左手双十一，右手阿里开源组件，不仅占据了程序员的购物车，还要攻占大家的开发工具。
最佳实践 架构师 微服务的前提
fei33423的专栏
01-10 302
1. 日志 : 收集系统 [flume ] 2. 日志结构化规范 3. 日志业务化规范. 把脉日志查询 内含 orderId,passengerId,driverId 等概念.找到对应的流水.同一个 flag 下 orderId 的收集,最终结构化查询] 4. flag 系统 5. 进阶之 zipkin 系统 . 新的耗时监控体系. 1. 把脉系统性能分析. 分位和...
微服务总结（一）
森的博客
09-26 839
前面的web网站演化讲到，为了解决上面拆分应用后所出现的问题，我们把公共的服务拆分出来，形成一种服务化的模式，简称SOA。走服务化的道路，现在出现微服务这个名词，搜集资料，总结如下： 目录如下： 一、微服务架构介绍 二、出现和发展 三、传统开发模式和微服务的区别 四、微服务的具体特征 五、SOA和微服务的区别 六、如何具体实践微服务 七、常见的微服务设计模式和应用 八、微服务的优...
微服务架构技术规范 v2
09-17
微服务架构技术规范 v2旨在定义和规范微服务架构的开发和实施过程中的最佳实践。以下是对该规范的回答： 微服务架构是一种将应用程序拆分成更小、更独立的服务的软件设计方法。它将整个应用程序划分为一组松耦合的服务，每个服务都独立运行和部署。微服务架构的目标是提高应用程序的可扩展性、灵活性和可维护性。 在微服务架构技术规范 v2中，有几个关键方面需要注意。首先是服务设计和拆分原则。规范建议根据业务功能和数据聚合程度来划分服务，避免服务之间的强耦合。此外，规范还提供了服务接口设计的准则，包括接口粒度、数据传输格式和错误处理等方面。 其次是服务的通信规范。规范推荐使用轻量级的通信协议，如REST或消息队列，以实现服务之间的通信。此外，规范还指导采用异步通信机制来提高系统的可伸缩性和性能。 规范 v2还强调了服务的部署和扩展策略。根据规范，服务应该以容器化的方式进行部署，如Docker。此外，规范还建议使用自动化的部署工具和容器编排平台，如Kubernetes，来实现服务的弹性扩展和管理。 最后，规范 v2还包含了其他方面的准则和最佳实践，如服务的监控和日志记录、安全性和权限控制、测试和质量保证等。 总体而言，微服务架构技术规范 v2为开发和实施微服务架构的项目提供了一套明确的指导原则和规范。遵循这些规范有助于确保微服务架构的一致性、可维护性和灵活性，提高开发团队的效率和系统的质量。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值