事务的统一性是微服务的一个重点问题,简洁有效的控制事务,更是程序员所需要的。JMS的诞生,就是为了更简单、更有效的控制事务。
先看一段调用微服务的代码:
using (var ms = new JMSClient())
{
//调用用户信息微服务,创建新用户
var uis = ms.GetMicroService();
var userid = uis.CreateUser();
//调用银行微服务,创建用户的银行账号
var bks = tran.GetMicroService();
bks.CreateBankAccount( userid );
//统一提交事务
ms.Commit();
}
代码中,分别调用了两个不同的微服务,做了一些业务操作,最后,通过Commit方法,统一提交这两个微服务的事务。
由于tran对象被using包裹,在这中间,任意一个代码发生异常,整体事务都会被回滚。
这样的代码风格,比较简洁,也符合一贯的编程习惯。
我们再看一下微服务端的代码:
UserInfoService:
public int CreateUser(TransactionDelegate tranDelegate)
{
var dbContext = new UserInfoDBContext();
//编写新增用户的业务代码
.........
//把数据库的事务提交和回滚,放到委托当中
tranDelegate.CommitAction = () => dbContext.CommitTransaction();
tranDelegate.RollbackAction = () => dbContext.RollbackTransaction();
return newUserId;
}
BankService:
public int CreateBankAccount(TransactionDelegate tranDelegate,int userid)
{
var dbContext = new BankDBContext();
//...编写创建银行账户的业务代码
//把数据库的事务提交和回滚,放到委托当中
tranDelegate.CommitAction = () => dbContext.CommitTransaction();
tranDelegate.RollbackAction = () => dbContext.RollbackTransaction();
return userBankId;
}
微服务写完业务逻辑,最后,把事务的提交和回滚放到委托当中,由框架自动调用。
JMS会在所有微服务执行完毕后,统一调用微服务挂起的委托,提交事务。如果有任意一个微服务执行出错、宕机或者离线,其他微服务的操作会被回滚,而离线的微服务,它所挂起的事务,也会在10秒之内回滚。
而分布式事务,有一种情况是无法避免的,就是最终统一提交事务时,虽然确认了各个微服务器响应正常,可以正常提交事务,这时候,所有服务器响应号召,提交了事务,但是,最后发现,有一台服务器宕机了。这种情况,是分布式系统无法避免的,但是,通过执行日志所提供的数据,可以把宕机的服务,手动再执行一次。
JMS特性
1、支持分布式事务控制;
2、支持分布式事务锁;
3、网关支持双机热备;
4、支持配置文件统一在网关部署、更新;
5、支持SSL双向校验;
6、可自定义定时任务;
7、负载均衡根据微服务的CPU使用率和当前请求数进行平均分配,也可自己编写负载均衡规则;
8、支持小巧的双重加密token(长度为68字符),实现用户无状态登录;
JMS支持的网络架构方案
方案1:只暴露应用服务器
这是应用服务器和微服务沟通,效率最高的方案,也是我们使用最多的。如果我们的服务器不是要部署在全国各地,那么可以多台服务器使用同一个局域网,只暴露应用服务器作为唯一的访问入口。
方案2:暴露应用服务器和代理服务器
服务器需要分布在不同的地域,为了安全起见,可以通过一个代理服务器,访问网关和微服务。
方案3:暴露所有服务器
服务器需要分布在不同的地域,为了更高的效率和更低的成本,可以把所有服务器暴露在互联网上,与服务器之间的通讯,经过SSL双向加密机制保证安全。
以上3个方案便是JMS所支持的网络架构,根据实际情况,自由配置适合自己的方案。
内容出处:,
声明:本网站所收集的部分公开资料来源于互联网,转载的目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。如果您发现网站上有侵犯您的知识产权的作品,请与我们取得联系,我们会及时修改或删除。文章链接:http://www.yixao.com/procedure/9836.html