微服务架构

使用nhmicro提供的micro-datasource嵌入式的解决微服务架构中分布式事务问题

与世无争的帅哥 提交于 2020-03-02 17:51:41
应用原理 : 使用micro-datasource数据源使事务与线程解耦,通过groupid在其他线程进行事务提交或回滚。 多个系统需要统一提交时,通过activemq发送提交消息(含有groupid),各系统收到消息后进行统一提交或回滚。 micro-datasource数据源与Mybatis或hibernate或jdbcTemplate等orm框架可以整合使用 原理是micro-datasource包中提供了路由数据源方案,通过aop动态切换普通数据源和分布式数据源 使用普通数据源时仍接受传统事务管理器管理 jar包下载: 需要使用nh-micro-datasource.jar 依赖 log4j.jar\org.springframework.beans.jar\org.springframework.aop.jar\org.springframework.core.jar\aopalliance.jar <dependency> <groupId>com.github.jeffreyning</groupId> <artifactId>nh-micro-datasource</artifactId> <version>1.0.0-RELEASE</version> </dependency> jms通知功能需要使用nh-micro-datasource-msg.jar

[译]API网关(API Gateway)

一世执手 提交于 2019-12-07 12:10:50
This a translation of an article ( http://microservices.io/patterns/apigateway.html ) originally written and copyrighted by Chris Richardson ( http://twitter.com/crichardson ). 模式:API网关 背景 我们假设你使用 微服务模式 创建一个在线商店,并正在实现商品详情页面。你需要开发多个版本的商品详情用户界面: 用于桌面和手机浏览器的基于HTML5/JavaScript的UI - HTML通过服务端web应用生成 本地Android和iPhone客户端 - 这些客户端通过REST API与服务器交互 另外,在线商店应该通过REST API 为第三方 公开 商品 详情。 商品 详情可以展示 商品 的许多信息。比如,Amazon.com上 POJOs in Action 详情页显示: 图书的基本信息,如标题,作者,价格等 图书的购买历史 是否有货 购买参数 与这本书同时被购买的商品 购买了这本书的用户还买了什么 用户评论 销售者的评分 ... 既然在线商店使用了微服务模式, 商品 详情数据通过服务来展开。如: 商品信息服务(Product Info Service) - 商品基本信息如标题,作者 价格服务

直播预告 | Rainbond与Service Mesh微服务架构

烈酒焚心 提交于 2019-12-01 03:46:28
本期主题 Rainbond与Service Mesh微服务架构 时间 2018年04月19日 本周四 晚8:00 直播大纲 浅谈微服务架构 api-gateway快速搭建微服务框架 Service Mesh加速传统应用服务化改造 通过Rainbond落地多种模式微服务 观看方式 提前五分钟加入ZOOM语音直播间 房间号 948-095-8255 直接进入 或 下载ZOOM 进入上述房间 Rainbond技术社群 微信扫描下方二维码,添加「入群接头人」并确认邀请入群 关于Rainbond Rainbond 是一款以应用为中心的开源PaaS,深度整合基于Kubernetes的容器管理、Service Mesh微服务架构最佳实践、多类型CI/CD应用构建与交付、多数据中心资源管理等技术,为用户提供云原生应用全生命周期解决方案,构建应用与基础设施、应用与应用、基础设施与基础设施之间互联互通的生态体系,满足支撑业务高速发展所需的敏捷开发、高效运维和精益管理需求。 来源: oschina 链接: https://my.oschina.net/u/584116/blog/1796784

Service Mesh服务网格:是什么和为什么

一笑奈何 提交于 2019-12-01 03:34:13
Service Mesh(服务网格)会是今年微服务生态的主角吗?从趋势来看,众多企业正在将这项理微服务复杂性的技术/工具,搬进他们的IT“火药库”之中。 什么是Service Mesh? 根据Linkerd CEO William Morgan定义,Service Mesh是用于处理服务间通信的基础设施层,用于在云原生应用复杂的服务拓扑中实现可靠的请求传递。在实践中,Service Mesh通常是一组与应用一起部署,但对应用透明的轻量级网络代理。 Service Mesh与传统基础设施层不同之处在于,它形成了一个分布式的互连代理网络,以sidecar形式部署在服务两侧,服务对于代理无感知,且服务间所有通信都由代理进行路由。 为什么需要Service Mesh? “Smart endpoint and dumb pipes”是微服务架构在集成服务时采用的一个核心理念,这一理念改变了过去臃肿集中的ESB(企业服务总线),无疑是正确方向上的一大进步,但同时也给我们出了一些难题——多智能才不会过于智能,而服务轻重大小的程度如何拿捏?我们应该如何处理微服务系统中服务间交互的复杂性?放在服务内部还是外部?如果是内部,如何处理业务逻辑关系,或者应该与基础设施更为相关?如果是外部,如何避免重蹈ESB的覆辙? 皮的不谈,先来看看处理服务间通信时需要关注的点: 服务发现 负载均衡 路由 流量控制