微服务的概念最早是在 2014 年由 Martin Fowler 和 James Lewis 共同提出,他们定义了微服务是由单一应用程序构成的小服务,拥有自己的进程与轻量化处理,服务依业务功能设计,以全自动的方式部署,与其他服务使用 HTTP API 通讯。同时,服务会使用最小规模的集中管理 (例如 Docker)技术,服务可以用不同的编程语言与数据库等。
微服务架构是一种软件架构模式,将单一应用程序划分成一个个小的服务,服务之间互相调用、或者通过网关调用运行。每个服务运行在其独立的系统进程中,服务与服务间采用轻量级的通信机制互相沟通(通常是基于HTTP的Rest API)。每个服务都围绕着具体业务进行构建,并且能够被独立地部署到各个软件环境等。
在传统型应用系统中, 虽然区分业务模块与基础模块,但是不能做到每个服务独立运行与部署. 那么在后台将是一个统一的服务体,对外提供服务.在用户访问前端使用负载均衡进行4-7的负载. 后台采用缓存、数据库、共享存储进行数据的共享. 在业务代码更新过程中, 不可避免的会影响到其他业务的系统。 而在上线之前,一般都会经历测试的阶段, 但是在业务系统庞大之后,不论每次软件版本功能的更新大与小,测试都是无法全面测试的。有时候甚至是在当时上线没有发现问题,可能会在下次发布或者是在其他的操作过程中,才发现问题。这样处理问题的故障定位就会异常的复杂,不能快速准确的定位问题.
微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步。基本上这种架构类型是移动互联网现在最流行的软件开发框架。在微服务架构中,集中式业务服务管理几乎不存在,微服务使用轻量级HTTP接口进行通信。
在SOA 架构发展之后,相比Micro Service 能够基于框架快速的开发应用程序, 甚至都不需要专用的启动web 服务, 来启动微服务. 而自身的软件框架已经携带。
在各个软件运行环境中(测试、开发、生产),运维与开发人员经常需要修改不同环境的配置文件, 在操作中可能会因为失误导致服务异常的情况,经常发生. 之前的SOA架构如果需要实现配置中心功能,那么需要借助第三方的配置中心, 但是这一切相对于微服务而言,实现起来比较简单,包括一系列的服务治理(服务管理手段)方案,在框架中早已经集成,大大降低了开发人员的工作负载,使得软件开发人员只需要专注于业务逻辑开发,而不需要关心软件框架的内部实现。
在后期的容器云中,客户端使用http协议的方式,使得微服务框架能够非常方便的融入docker.并且通过docker 的ingress 功能实现对服务的弹性负载均衡.
优势复杂度可控(复杂度降低) 在将业务应用拆分之后,使原本复杂的应用,变得简单。每一个微服务只有单一的某一项功能,并通过定义良好的接口调用模式,使客户端调用更加简单。由于”体积”小、复杂度低,每个微服务可由一个小规模开发团队完全掌控,易于保持高可维护性和开发效率。
大部分的开发者经历和开发过单体应用,无论是传统的 Servlet + JSP,还是 SSM,还是现在的 SpringBoot,它们都是单体应用,那么长期陪伴我们的单体应用有什么弊端?我们是面临了什么问题,导致我们要抛弃单体应用转向微服务架构?主要原因如下:
微服务架构的特点:针对特定服务发布,影响小,风险小,成本低;频繁发布版本,快速交付需求;低成本扩容,弹性伸缩,适应云环境。 我们知道一个朴素的理念,没有任何事物是完美的,任何东西都有两面性,有得必有失,那么在选择微服务在解决了快速响应和弹性伸缩的问题同时,它又给我们带来了什么问题?简单总结如下:
部署,测试和监控的成本问题
分布式事务和CAP的相关问题
系统应用由原来的单体变成几十到几百个不同的工程,会所产生例如包括服务间的依赖,服务如何拆封,内部接口规范,数据传递等等问题,尤其是服务拆分,需要团队熟悉业务流程,懂得取舍,要保证拆分的粒度服务既符合“高内聚,低耦合”的基本原则,还要兼顾业务的发展以及公司的愿景,要还要说服团队成员为之努力,并且积极投入,在多方中间取得平衡。
对于分布式系统,部署,测试和监控都需要大量的中间件来支撑,而且中间件本身也要维护,原先单体应用很简单的事务问题 ,转到分布式环境就变得很复杂,分布式事务是采用简单的重试+补偿机制,还是采用二阶段提交协议等强一致性方法来解决,就要取决对业务场景的熟悉加上反复的权衡了,相同问题还包括对 CAP 模型的权衡,总之微服务对团队整体的技术栈水平整体要求更高
特征 自动化部署,端点智能化,语言和数据的去中心化控制.
架构 一种将一个单一应用程序开发为一组小型服务的方法,每个服务运行在自己的进程中,服务间通信采用轻量级通信机制(通常用HTTP资源API)。可通过全自动部署机制独立部署,共用一个最小型的集中式的管理。服务可用不同的语言开发,使用不同的数据存储技术。
去中心化基础设施
去中心化数据库
聚合式(推荐)
代理(推荐)
链式
分支
异步消息
通信方式 REST和RPC RPC框架
阿里巴巴公司开源的一个Java高性能优秀的服务框架,可以和Spring框架无缝集成,相关资料很丰富。 遗憾的是已经停止维护了,相关的依赖类比如Spring,Netty还是很老的版本。倒是当当网之类的再继续维维护,即Dubbox,并且实现了REST的支持。 Dubbo主要实现了服务治理,其他为保证集群安全、可维护、可测试等特性方面都没有很好的实现,但是几乎大部分关键组件都能找到第三方开源来实现。 所以,如果选择Dubbo请务必在各个环节做好整套解决方案的准备,不然很可能随着服务数量的增长,整个团队都将疲于应付各种架构上不足引起的困难,不能让各环节人员真正的专注于业务逻辑。
Motan 新浪微博的服务治理框架,2016年5月开源,Motan是一个小而精的 RPC 框架,它的特点是简单、易用,是一个轻量级 RPC框架。 与Dubbo相比,Motan在功能方面并没有那么全面,也没有实现特别多的扩展。用的人比较少,功能和稳定性有待观望。对跨语言调用支持较差,主要支持java。
Sprint Cloud(推荐) Spring Cloud 完全基于Spring Boot,是一个非常新的项目,2016年才 1.0 release。版本提升非常迅速,发展势头良好。 Spring Cloud依然发扬了Spring Source整合一切的作风,以标准化的姿态将一些微服务架构的成熟产品与框架揉为一体,并继承了Spring Boot简单配置、快速开发、轻松部署的特点,让原本复杂的架构工作变得相对容易上手一些。服务调用方式是基于REST API的。 缺点是项目很年轻,很少见到国内业界有人在生产上成套使用,一般都是只有其中一两个组件。相关的技术文档大部分是英文的,案例也相对较少,使用的话需要摸索的时间会长一些。
gRPC Google发布的开源RPC框架,高性能、开源、将移动和HTTP/2放在首位的通用的RPC框架,基于HTTP/2, netty4.1, proto3, 拥有非常丰富而实用的特性,堪称RPC 框架的典范。 但它本身它不是分布式的,所以要实现上面的框架的功能需要进一步的开发
Spring Cloud和Dubbo都是微服务开发框架。不是新的技术就一定是好的技术。Dubbo优势在于开发简单,效率高。Spring Cloud优势在于功能全面且可靠性高。
开发中,使用的框架版本,最好是RELEASE版本或Final版本。 常见版本号格式为: x.y.z.stage
2. Spring Cloud版本号说明 Spring Cloud是一个包含若干子框架的框架集合体,是一个完整的微服务框架体系,如果使用场景版本号来进行标记,容易混淆主框架版本和子框架版本标记。所以Spring Cloud使用一种全新的版本号来对主框架进行版本标记,而子框架的版本标记大多还是使用常用版本号标记的。 Spring Cloud版本格式如: 版本号命名.stage 版本号命名:Spring Cloud主框架版本号是使用英国伦敦地铁站名称来进行标记的,并根据地铁站名称的首字母的英文自然升序排列来识别版本的递增。如:Angle、Brixton、Camden、Dalston、Edgware、Finchley等。后续版本提升会继续根据首字母升序排列。