什么是微服务
欢迎关注微信公众号: 程序员小圈圈
原文首发于: www.zhangruibin.com
本文出自于: RebornChang的博客
转载请标明出处^_^
为什么要了解微服务
记得三年前,笔者来京面试工作,好几家公司都问我:了解Springboot吗,用过吗?
但是也是那句话,那是三年前,现在面试问什么?
架构,底层,协议,算法 ETC。
那如果问潮流点的东西呢?一般就是微服务了。
啥?你没有用过?没关系,那你说说你认识的微服务吧。
啥??你没了解过?没关系,接下来来看笔者的一系列关于微服务架构的文章吧。
首先说下概念,什么是微服务?
什么是微服务
通常来说我们这么来定义微服务是什么:
微服务是一种架构风格,是以开发一组小型服务的方式来作为一个独立的应用系统,每个服务都运行在自已的进程中,服务之间采用轻量级的HTTP通信机制 ( 通常是采用HTTP的RESTful API )进行通信。这些服务都是围绕具体业务进行构建的,并且可以独立部署到生产环境上。这些服务可以用不同的编程语言编写,并且可以使用不同的数据存储技术。对这些微服务我们只需要使用一个非常轻量级的集中式管理来进行协调。
通俗点来讲,就是我们把一个采购下单流程,分成不同的子系统。
比如订单系统,商品系统,购物车系统,账户系统,支付系统等等。
从这个拆分我们也能明显的看出来,这样做的话会分工明确,达到系统解耦的效果,但是也会增加维护成本,总结下优缺点大致如下:
微服务的优缺点
优点:
-
易于开发和维护:一个微服务只会关注一个特定的业务功能,所以业务清晰、代码量较少,开发和维护单个微服务相对简单;
-
单个微服务启动较快;
-
局部修改容易部署:单一应用只要有修改,就得重新部署整个应用。微服务解决了这样的问题。一般来说,对某个微服务进行修改,只需要重新部署这个服务即可;
-
技术栈不受限制:在微服务架构中,可以结合项目业务及团队的特点,合理的选择技术栈。
-
按需伸缩:可根据需求,实现细粒度的扩展。
缺点: -
运维要求高:更多的服务意味着要投入更多的运维;
-
分布式固有的复杂性:使用微服务构建的是分布式系统。对于一个分布式系统,系统容错、网络延迟、分布式事务等都会带来巨大的问题;
-
接口调整成本高:微服务之间通过接口进行通信。如果修改某一个微服务的API,可能所有用到这个接口的微服务都需要进行调整。
微服务的技术栈
把微服务说的如此的厉害,那没有微服务之前我们就不做系统了吗?不是的,那么换句话来说,微服务的技术实现有哪些?对标的技术有哪些?对比有哪些优劣?
看接下来的文字。
微服务技术 | 技术实现 |
---|---|
服务开发 | Spring Boot、Spring、Spring MVC等 |
服务注册与发现 | Eureka、Zookeeper等 |
服务调用 | Rest、RPC等 |
服务熔断器 | Hystrix、Envoy等 |
负载均衡 | Ribbon、Nginx等 |
服务接口调用(客户端调用服务的简化工具) | Feign等 |
消息队列 | Kafka、ActiveMQ等 |
服务配置中心管理 | Spring Cloud Config等 |
服务路由(API网关) | Zuul等 |
服务监控 | Zabbix、Nagios等 |
全链路追踪 | Zipkin,Brave等 |
服务部署 | Docker、OpenStack等 |
数据流处理 | Spring Cloud Stream(Redis,Rabbit,Kafka等发送接收消息) |
事件消息总线 | Spring Cloud Bus |
那有的人就说了,我服务部署不用Docker之类的技术不行吗?可以的,我就用老的SSH,war包形式Tomcat部署也行,没有一个特定的标准来说怎样才是完美的服务,适合的才是最好的,上面说的那些技术实现,是一整套的体系,可以帮我们省很多的事。
那些技术栈很多朋友会感觉眼熟,怎么像Springcloud的一些东西?我们称之为组件。是的,那么接下来我们延伸到springcloud。
什么是 Spring Cloud
-
Spring Cloud,基于 Spring Boot 提供了一套微服务解决方案,包括服务注册与发现,配置中心,全链路监控,服务网关,负载均衡,熔断器等组件,除了基于NetFlix的开源组件做高度抽象封装之外,还有一些选型中立的开源组件。
-
官方译文:构建分布式系统不用特别的复杂且避免容易出现的错误。Spring Cloud为最常见的分布式系统模式提供了一个简单和可访问的编程模型,帮助开发人员构建弹性、可靠和协调的应用程序。SpringCloud构建在SpringBoot之上,使开发人员很容易开始工作并迅速提高生产力。
看完了上面的文字概念,我们来张技术架构图看看Springcloud的整体架构是怎样的:
看了那个架构图,仔细体会下,抛开Springcloud,是不是有些眼熟?是的,Springcloud在一定程度上的功能类似于dubbo+zookeeper。
那么接下来笔者会简单比较下二者的区别。
核心要素 | Dubbo | SpringCloud |
---|---|---|
服务注册中心 | Zookeeper、Redis | Spring Cloud Netflix Eureka |
服务调用中心 | RPC | REST API |
服务网关 | 无 | Spring Cloud Netflix Zuul |
断路器 | 不完善 | Spring Cloud Netflix Hystix |
分布式配置 | 无 | Spring Cloud Config |
分布式追踪系统 | 无 | Spring Cloud Sleuth |
消息总线 | 无 | Spring Cloud Bus |
数据流 | 无 | Spring Cloud Stream 基于Redis,Rabbit,Kafka实现的消息微服务 |
批量任务 | 无 | Spring Cloud Task |
从上面这个表格我们可以简述为以下陈述:
Dubbo 只是实现了服务治理,而 Spring Cloud 子项目分别覆盖了微服务架构下的众多部件,服务治理只是其中的一个方面。
Dubbo 提供了各种 Filter,对于上述中“无”的要素,可以通过扩展 Filter 来完善。例如:
-
分布式配置:可以使用淘宝的 diamond、百度的 disconf 来实现分布式配置管理。
-
服务跟踪:可以使用京东开源的 Hydra,或者扩展 Filter 用 Zippin 来做服务跟踪。
-
批量任务:可以使用当当开源的 Elastic-Job、tbschedule
点评
从核心要素来看,Spring Cloud 更胜一筹,在开发过程中只要整合Spring Cloud 的子项目就可以顺利的完成各种组件的融合,而 Dubbo 却需要通过实现各种 Filter 来做定制,开发成本以及技术难度略高。
##性能比较
使用一个Pojo对象包含10个属性,请求10万次,Dubbo 和 Spring Cloud 在不同的线程数量下,每次请求耗时(ms)如下
线程数 | Dubbo | Spring Cloud |
---|---|---|
10线程 | 2.75 | 6.52 |
20线程 | 4.18 | 10.03 |
50线程 | 10.3 | 28.14 |
100线程 | 20.13 | 55.23 |
200线程 | 42 | 110.21 |
说明:客户端和服务端配置均采用阿里云的 ECS 服务器,4 核 8G 配置,Dubbo 采用默认的 Dubbo 协议。
点评
Dubbo 支持各种通信协议,而且消费方和服务方使用长链接方式交互,通信速度上略胜 Spring Cloud,如果对于系统的响应时间有严格要求,长链接更合适。
总的来说
Dubbo 出生于阿里系,是阿里巴巴服务化治理的核心框架,并被广泛应用于中国各互联网公司;只需要通过 Spring 配置的方式即可完成服务化,对于应用无入侵,设计的目的还是服务于自身的业务为主。虽然阿里内部原因 Dubbo 曾经一度暂停维护版本,但是框架本身的成熟度以及文档的完善程度,完全能满足各大互联网公司的业务需求。如果我们使用配置中心、分布式跟踪这些内容都需要自己去集成,这样无形中增加了使用 Dubbo 的难度。
Spring Cloud 是 Spring 家族的产品, 专注于企业级开源框架的研发。Spring Cloud 自从发布到现在,仍然在不断的高速发展,几乎考虑了服务治理的方方面面,开发起来非常的便利和简单。
Dubbo 于 2017 年开始又重启维护,发布了更新后的 2.5.7 版本,而 Spring Cloud 更新的非常快,目前已经更新到 Finchley.M2。因此,企业需要根据自身的研发水平和所处阶段选择合适的架构来解决业务问题,不管是 Dubbo 还是 Spring Cloud 都是实现微服务有效的工具。
微服务架构是互联网很热门的话题,是互联网技术发展的必然结果。它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。
接下来笔者将从0到1搭建一个简单的微服务项目以供学习参考,如果您感兴趣请关注公众号接下来关于SpringCloud的文章推送哦~~
亲,博主的微信公众号
‘程序员小圈圈’开始持续更新了哟~~
识别二维码或者直接搜索名字 ‘程序员小圈圈’ 即可关注本公众号哟~~
不只是有技术哟~~
还有很多的学习娱乐资源免费下载哦~~
还可以学下教育知识以及消遣娱乐哟~~
求关注哟~~ ’