微服务的理解

微服务是一个架构概念,他希望通过将功能分解到个个零散的服务中,以实现对解决方案的解耦,并提供更加灵活的服务支持,

微服务是吧一个大型的单个应用程序和服务拆分成数个,甚至数十个支持的微服务,他可扩展单个组件而不是整个的应用程序堆栈,从而满足服务等级协议,微服务他是围绕业务领域组件来创建应用,这些应用可以独立的进行开发管理和迭代,在组件中使用云架构和平台式部属管理和服务耦合功能,使产品交付更加简单,他的本质是用一些功能明确,业务比较精炼的的服务去解决更大,更 实际的问题,

如图下图是微服务简单的架构图:

微服务的理解

官方的定义是:微服务是独立的服务共同 组成整个系统,其次是单个部署每个跑在自己的进程中,每个服务为独立的业务开发,是分布式管理的,非常强调隔离性,1.分布式组成的系统,2.按照业务而不是按照技术来划分组织,3.他是有生命的产品,而不是项目,4.他是强服务个体,弱通信 5.自动化运维,6.具有高度的容错性,7.可以快速的液化和迭代,

微服务通常是由重写一个模块开始的,要想把整个特别大的应用重写,是由很大的风险的,不过也不一定有那必要了,我们像微服务迁移的时候通常通过耦合度最低的模块,或者对扩展性最高的模块开始,把他们一个一个剥离出来,用敏捷重写,可以尝试最新的技术和语言,框架,单独部署,他通常不依赖于其他服务,微服务中常用的api gateway,他的模式主要目的也不是重用代码,而且减少客户端,和服务间的往来,微服务,通常是直接面对用户的,每个服务通常是直接为用户提供某个功能,比如针对手机用一个服务,针对pc是另外一个服务

使用微服务需要四个问题:

1:客户端如何访问这些服务

2:每个服务之间是如何通信的

3:如此多的服务如何实现

4:服务挂了该如何解决

问题解决:

1:客户端如何访问这些服务,

假设我们按功能拆分了独立的服务,跑在独立的虚拟机上,他们是独立的java进程,那么就需要 一个代理或者我们可以叫做api gateway,他的作用主要包括提供统一的服务入口,让微服务跟前台透明,同时他可以聚合后台的服务,节省流量,提供性能,同时他又提供安全,过滤,留空的api的管理功能,因此我们在说客户端如何访问这些服务的时候,核心api gateway来进行处理

2:每个服务之间是如何通信的,

目前有许多存储的方案,异步的话,主要通过消息队列,比如kafa,同步调用包含两种,使用rest或者是rpc,rest可以使用jacs rs,或者是spring boot,rbc通常使用dubbo,

同步与异步的区别,一般同步调用比较简单他一致性强 但是容易出现调用问题,性能体现差,特别是调用层次多的时候,一般rest是基于http的更容易实现,也更容易被接受服务端实现技术也更灵活点,个个语言都能支持 同时能跨客户端对客户端没有特殊的要求,只要封装了http的sdk就能调用,所以相对使用的广些,同步的rbc也有自己的 优点,他的传输协议更高效,安全也更可控,异步技能减少调用服务之间的耦合又能成为调用之间的缓冲,确保消息挤压不会冲垮被调用方,同时能保证服务方的体验,自己做自己的活,不至于被后台服务拖,不过付出的代价是一致性减弱,需要接受数据的最终一致性

3:如此多的服务如何实现

在微服务架构中一般每个服务都是有多个拷贝来做负责均衡,一个服务随时可能下线,也可能临时应对访问压力临时增加新的服务节点,服务之间如何相互感知,服务如何管理这就是服务发现的问题了,基本上都是通过zukper等类似技术做服务注册等信息的分布式管理当服务上线时服务提供者将自己的服务信息注册到zk或者类似的框架,并通过心跳维持长连接,实时更新连接信息服务调用者,通过zk去寻找地址根据可定制的算法找到一个服务,还可以将服务的信息缓存到本地来提高性能

4:服务挂了该如何解决

分布式最大的特性是网络不可靠,通过微服务拆分能降低风险,不过没有特别的保障结局肯定也不理想,所以当我们的系统有一系列服务调用链组成的时候,我们必须确保任何一个环节出问题,都不至于影响到整个链路,这是会有相应的手段,如从事机制,应用的线流,熔断机制,负载均衡,系统降级等,