微服务(Microservices Architecture)是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下,每个任务代表着一个小的业务能力。
微服务的概念源于2014年3月Martin Fowler所写的文章“Microservices” martinfowler.com/articles/mi…
企业级的应用一般都会面临各种各样的业务需求,而常见的方式是把大量功能堆积到同一个单体架构中去。比如:常见的ERP、CRM等系统都以单体架构的方式运行,同时由于提供了大量的业务功能,随着功能的升级,整个研发、发布、定位问题,扩展,升级这样一个“怪物”系统会变得越来越困难。
这种架构模式就是把应用整体打包部署,具体的样式依赖本身应用采用的语言,如果采用java语言,自然你会打包成war包,部署在Tomcat或者Jetty这样的应用服务器上,如果你使用spring boot还可以打包成jar包部署。其他还有Rails和Node.js应用以目录层次的形式打包
上图:单体架构
大部分企业通过SOA来解决上述问题,SOA的思路是把应用中相近的功能聚合到一起,以服务的形式提供出去。因此基于SOA架构的应用可以理解为一批服务的组合。SOA带来的问题是,引入了大量的服务、消息格式定义和规范。
多数情况下,SOA的服务直接相互独立,但是部署在同一个运行环境中(类似于一个Tomcat实例下,运行了很多web应用)。和单体架构类似,随着业务功能的增多SOA的服务会变得越来越复杂,本质上看没有因为使用SOA而变的更好。图1,是一个包含多种服务的在线零售网站,所有的服务部署在一个运行环境中,是一个典型的单体架构。
单体架构的应用一般有以下特点:
微服务架构的核心思想是,一个应用是由多个小的、相互独立的、微服务组成,这些服务运行在自己的进程中,开发和发布都没有依赖。不同服务通过一些轻量级交互机制来通信,例如 RPC、HTTP 等,服务可独立扩展伸缩,每个服务定义了明确的边界,不同的服务甚至可以采用不同的编程语言来实现,由独立的团队来维护。简单的来说,一个系统的不同模块转变成不同的服务!而且服务可以使用不同的技术加以实现!
上图:微服务架构
那我们在微服务中应该怎样设计呢。以下是微服务的设计指南:
在单体架构中,不同功能之间通信通过方法调用,或者跨语言通信。SOA降低了这种语言直接的耦合度,采用基于SOAP协议的web服务。这种web服务的功能和消息体定义都十分复杂,微服务需要更轻量的机制。
同步消息就是客户端需要保持等待,直到服务器返回应答。REST是微服务中默认的同步消息方式,它提供了基于HTTP协议和资源API风格的简单消息格式,多数微服务都采用这种方式(每个功能代表了一个资源和对应的操作)
异步消息就是客户端不需要一直等待服务应答,有应到后会得到通知。某些微服务需要用到异步消息,一般采用AMQP, STOMP, MQTT 这三种通讯协议
消息格式是微服务中另外一个很重要的因素。SOA的web服务一般采用文本消息,基于复杂的消息格式(SOAP)和消息定义(xsd)。微服务采用简单的文本协议JSON和XML,基于HTTP的资源API风格。如果需要二进制,通过用到Thrift, ProtoBuf, Avro。
如果把功能实现为服务,并发布,需要定义一套约定。单体架构中,SOA采用WSDL,WSDL过于复杂并且和SOAP紧耦合,不适合微服务。
REST设计的微服务,通常采用Swagger和RAML定义约定。
对于不是基于REST设计的微服务,比如Thrift,通常采用IDL(Interface Definition Languages),比如Thrift IDL。
大部分微服务基于RPC、HTTP、JSON这样的标准协议,集成不同标准和格式变的不再重要。另外一个选择是采用轻量级的消息总线或者网关,有路由功能,没有复杂的业务逻辑。下面就介绍几种常见的架构方式。
点对点方式中,服务之间直接用。每个微服务都开放REST API,并且调用其它微服务的接口。
上图:通过点对点方式通信
很明显,在比较简单的微服务应用场景下,这种方式还可行,随着应用复杂度的提升,会变得越来越不可维护。这点有些类似SOA的ESB,尽量不采用点对点的集成方式。
API网关方式的核心要点是,所有的客户端和消费端都通过统一的网关接入微服务,在网关层处理所有的非业务功能个。通常,网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。
上图:通过API-网关暴露微服务
所有的业务接口通过API网关暴露,是所有客户端接口的唯一入口。微服务之间的通信也通过API网关。/
采用网关方式有如下优势:
目前,API网关方式应该是微服务架构中应用最广泛的设计模式。
微服务也可以集成在异步的场景下,通过队列和订阅主题,实现消息的发布和订阅。一个微服务可以是消息的发布者,把消息通过异步的方式发送到队列或者订阅主题下。作为消费者的微服务可以从队列或者主题共获取消息。通过消息中间件把服务之间的直接调用解耦。
上图:异步通信方式
通常异步的生产者/消费者模式,通过AMQP, STOMP, MQTT 等异步消息通讯协议规范。
单体架构中,不同功能的服务模块都把数据存储在某个中心数据库中。
每个微服务有自己私有的数据库,其它微服务不能直接访问。单体架构,用一个数据库存储所有数据
微服务方式,多个服务之间的设计相互独立,数据也应该相互独立(比如,某个微服务的数据库结构定义方式改变,可能会中断其它服务)。因此,每个微服务都应该有自己的数据库。
每个微服务有自己私有的数据库,其它微服务不能直接访问。每个微服务有自己私有的数据库,其它微服务不能直接访问。
数据去中心话的核心要点:
数据的去中心化,进一步降低了微服务之间的耦合度,不同服务可以采用不同的数据库技术(SQL、NoSQL等)。在复杂的业务场景下,如果包含多个微服务,通常在客户端或者中间层(网关)处理。
微服务的一些想法在实践上是好的,但当整体实现时也会呈现出其复杂性。
最后给大家带来一波福利
最新架构视频免费获取哦
时代在变,技术在变, IT行业对程序员的要求是越来越高,现在的程序员需要学习的东西更多了, 确实是更加辛苦了,当然,能力也更强了。
在现在互联网寒冬中java程序员求职越来越难,面试中要求掌握的技术也是越来越难,那么我们到底需要掌握哪些技术才不会被淘汰呢?
小编就职于某BAT大厂多年,现在也整理出来一套java进阶学习路线图,文末领取高清大图!!
设计模式与Spring源码解读
自动化工具
工欲善其事必先利其器,不管是小白,还是资深开发,玩Java技术体系,选择好的工具,提升开发效率和团队协作效率,是必不可少的:
Maven,项目管理
Jenkins,持续集成
Sonar,代码质量管理
Git,版本管理
微服务专题
业务越来越复杂,服务分层,微服务架构是架构升级的必由之路,Java技术体系,和微服务相关的技术有哪些呢?
微服务框架
Spring Cloud
Docker与虚拟化
微服务架构
高并发分布式专题
高并发,高可用,海量数据,没有分布式的架构知识肯定是玩不转的:
分布式架构原理
分布式架构策略
分布式中间件
分布式架构实战
性能优化专题
任何脱离细节的ppt架构师都是耍流氓,向上能运筹帷幄,向下能解决一线性能问题,Java技术体系,需要了解:
性能指标体系
JVM调优
Web调优
DB调优
头条篇幅有限,脑图还是放不下一整副的,收集这个脑图也是让自己身边很多大牛都参与过,所以也算现在Java行业最全最新的啦,现在作为粉丝福利,免费送给大家,大家可以关注我后私聊我【Java】免费领取
如何一起学习,有没有免费资料?
以上是自己收集总结的Java架构技术图谱,自己因为比较喜欢技术,所以收集了一些Java高并发、分布式、JVM、spring、源码分析和kafka等架构技术资料,如果你也对技术感兴趣可以来关注我
资料领取方式:转发+收藏后加入群聊809389099即可免费获取
资料领取方式: 转发+收藏后加入群聊809389099即可免费获取