回目录 《微服务架构》

什么是微服务

首先微服务是啥,微服务首先是一种架构思想, 首先最初的很多产品都是单体monolithic架构,所有的服务都紧紧耦合在一个解决方案中,难以扩展,只能通过加cpu加内存的方式扩展,举例一个电商平台, 刚开始所有功能都放在一个解决方案,比如托管在Apache的一个war或者托管在iis的一个.net mvc程序, 随着项目的发展,团队的壮大,单体会变得庞大而难以维护,我们需要将功能拆分开,比如商家系统、买家系统、管理后台系统等,面向业务或者叫服务切分,分而治之,这种粒度的就是SOA架构,

其显著缺点:

1.从技术的角度,其实业务的切分在技术层面上仍然会有大面积的重叠,因此如果业务切割的不好,形成各种依赖,有可能在修改时牵一发而动全身

2.从业务角度来说,由于是业务的切分,所以当需要发展新的业务时就需要重新构建一个完全新的服务,不利于基于业务创新和发现

所以引入微服务的概念,微服务进一步将服务自底向上或自上到下做更细的切分,最下面是基础系统服务(短信、邮件、存储、缓存、消息推送等),中间是共享服务(支付系统、订单系统、仓储系统等), 最上面则是业务层(零售系统、团购系统、采购系统),比如我们要加一个闪购业务也是很轻松的,不用从底到上再来一遍,只需要基于基础服务和共享服务做业务开发

微服务引入的问题和解决方法

1.事务的处理

单体程序在单个JVM上跑,事务容易处理,不同的微服务跑在不同的JVM,事务控制需要处理;

采用kafka的exactly once语义;

采用alibaba-seata 微服务分布式事务4种解决方案实战

2.服务交互方式

不同的微服务之间如何交互,同一个微服务的多个副本如何协同分配任务

API调用+nginx反向代理

注册中心zookeeper+RPC调用; 注册中心nacos+restAPI调用+ribbon负载均衡+feign接口

基于消息的订阅

相关技术实现:

注册中心: zookeeper nacos

3. 微服务也有单点故障

单体解决方案有单点故障我们都清楚,其实微服务也存在单点故障,比如机票预订系统,假设用户预订机票会调用BookingService, 然后BookingService会调用另外几个微服务:

//创建账单
orderService.createOrder();
//
//增加用户积分
userCreditService.increase();
//给用户发邮件

//给航班调度安排部门发信息

当然你可能说一般都是分几步做的,比如创建订单,付款,然后才会增加积分和后续操作,这里我们只是举例,并非真实业务场景;

下订单后调用加积分,如果积分服务挂掉,不应该影响下订单的主要业务, 单点故障: 1)启动多个相同服务,可以缓解单点故障 2)业务依赖的单点故障, 最简单做法try catch加积分的调用,更好方法是采用sentinel(可以用feign加fallback)

4. 客户端请求:

1)认证授权:

传统基于session: 传统的单体应用可能习惯了session的存在,而到了Spring cloud的微服务化后,session虽然可以采取分布式会话来解决,但终究不是上上策。开始有人推行Spring Cloud Security结合很好的OAuth2,后面为了优化OAuth 2中Access Token的存储问题,提高后端服务的可用性和扩展性,有了更好Token验证方式JWT(JSON Web Token)。这里要强调一点的是,OAuth2和JWT这两个根本没有可比性,是两个完全不同的东西。 OAuth2是一种授权框架,而JWT是一种认证协议

有很多客户端,手机、网站、第三方,甚至网站还有各种二级网站需要支持sso,传统做法是登录后将session放到缓存比如redis,

基于token: 但是对于亿级用户级别,采用基于token的方式

2)请求路由

LVS负载均衡=>nginix=>网关系统gateway(spring.cloud.gateway)+请求路由

限流:
	最原始redis计数器,更好的办法是使用sentinel