谈到微服务,我们先来见见它的面试题:
常见面试题
1、什么是微服务
2、微服务之间是如何独立通信的?
3、SpringCloud和Dubbo有哪些区别
4、SpringBoot和SpringCloud,请你谈谈对他们的理解
5、什么是服务熔断?什么是服务降级
6、微服务的优缺点分别是哪些?说下你在项目中遇到的坑
7、你所知道的微服务技术栈有哪些?请列举一二
8、EureKa和zookeeper都可以提供服务注册和发现的功能,请说说两个的区别?
微服务
微服务就是将业务拆成一个个服务,实现彻底的解耦,其实一个服务就相当于IDEA中的一个模块,一个模块只做一个功能。
推荐大家观看微服务的中文介绍:https://www.cnblogs.com/liuning8023/p/4493156.html
微服务的优缺点
优点:
- 单一职责原则
- 每个服务足够内聚,足够小,代码容易理解,这样就能聚焦一个指定的业务功能或者业务需求
- 开发简单,开发效率提高,一个服务可能就是专一只干一件事
- 微服务能够被小团体单独开发,这个小团体是2~5人的开发人员组成
- 微服务是松耦合的,是有功能意义的服务,无论是开发阶段或者部署阶段都是独立的
- 微服务使用不同的语言开发
- 易于第三方集成,微服务允许任意且灵活的方式集成自动部署,通过持续集成工具,如Jenkins、Hudson、bamboo
- 微服务易于被一个开发人员理解,修改和维护,这样的小团体能够关注自己的工作成果,无需通过合作才能体现价值
- 微服务允许你利用融合最新即使
- 微服务只是业务逻辑代码,不会和HTML、CSS或者其他的界面混合
- 每个微服务都有自己的存储功能,可以有自己的数据库,也可以有统一的数据库
缺点:
-
开发人员要处理分布式系统的复杂性
-
多服务运维难度,随着服务增加,运维的压力也在增大
-
系统部署依赖
-
服务间通信成本
-
数据一致性
-
系统集成测试
-
性能监控
微服务架构
简而言之,微服务架构风格,就像是把一个单独的应用程序开发为一套小服务,每个小服务运行在自己的进程中,并使用轻量级机制通信,通常是 HTTP API。这些服务围绕业务能力来构建,并通过完全自动化部署机制来独立部署。
提到微服务架构,就不得不提微服务架构四个核心问题:
- 服务(订单服务、交易服务、支付服务、物流服务、评论服务)很多,客户端应该怎样访问这些服务
- 服务之间是如何通信的(HTTP、RPC)
- 这么多服务,应该如何管理
- 突然其中一个服务挂了,其他服务该怎么办
解决上面的四个问题有三种解决方案:
第一种解决方案:
Spring Cloud NetFilx一站式解决方案
API网关:zuul组件
Feign–HTTPClient–Http通信方式,同步,阻塞
服务注册发现:EureKa
熔断机制:Hystrix
第二种解决方案:
Apache Dubbo Zookeeper,半自动,需要整合别人的插件
API:没有,找第三方组件,或者自己实现
Dubbo:使得应用可通过高性能的 RPC 实现服务的输出和输入功能,实现高可用
zookeeper:是一个分布式的,开放源码的分布式应用程序协调服务,提供的功能包括:配置维护、域名服务、分布式同步、组服务等。
没有熔断机制:借助Hystrix
第三种解决方案:
Spring Cloud Alibaba–最新的一站式解决方案,更简单
其实上面三种解决方案的本质是:
- API网关
- HTTP、RPC通信协议
- 服务注册和发现
- 熔断机制
微服务技术栈有哪些
微服务条目 | 落地技术 |
---|---|
服务开发 | SpringBoot、Spring、SpringMVC |
服务配置和管理 | Netflix公司的Archaius、阿里Diamond |
服务注册和发现 | EureKa、Consul、zookeeper等 |
服务调用 | Rest、RPC、gRPC |
服务熔断器 | Hystrix、Envoy等 |
负载均衡 | Ribbon、Nginx等 |
服务接口调用(客户端调用服务简化工具) | Feign等 |
消息队列 | Kafka、Rabbitmq、ActiveMq等 |
服务配置中心管理 | SpringCloudConfig、chef等 |
服务路由(API网关) | Zuul等 |
服务监控 | Zabbix、Nagios、Metrics、Specatator等 |
全链路追踪 | Zipkin、Brave、Dapper等 |
服务部署 | Docker、OpenStack、Kubernetes等 |
数据流操作开发包 | SpringCloud Stream(封装与Redis、Rabbit、Kafka等发送接收消息) |
事件消息总线 | SpringCloud Bus |
为什么要是用SpringCloud作为微服务架构
选择依据
- 整体解决方案和框架成熟
- 社区热度高
- 可维护性
- 学习曲线,简单
当前各大网络公司用的微服务架构有哪些?
-
阿里:Dubbo+HFS
-
京东:JSF
-
新浪:Motan
-
当当网:DubboX
各微服务框架比较
功能点/服务框架 | Netflix/SpringCloud | Motan | gRPC | Thrift | Dubbo/DubboX |
---|---|---|---|---|---|
功能定位 | 完整的微服务架构 | RPC框架,但整Zk或Consul,实现集群环境的基本服务注册/发现 | RPC框架 | RPC框架 | 服务框架 |
支持Rest | 是,Ribbon支持多种可插拔的序列化选择 | 否 | 否 | 否 | 否 |
支持RPC | 否 | 是(Hession2) | 是 | 是 | 是 |
支持多语言 | 是(Rest形式) | 否 | 是 | 是 | 否 |
负载均衡 | 是(服务端zuul+客户端Ribbon),zuul-服务,动态路由,云端负载均衡EureKa(针对中间层服务器) | 是(客户端) | 否 | 否 | 是(客户端) |
配置服务 | Netflix Archaius,SpringCloud Config Server集中配置 | 是(zookeeper提供) | 否 | 否 | 否 |
服务调用链监控 | 是(zuul)、zuul提供边缘服务,API网关 | 否 | 否 | 否 | 否 |
高可用/容错 | 是(服务端Hystrix+客户端Ribbon) | 是(客户端) | 否 | 否 | 是(客户端) |
典型案例 | Netflix | Sina | |||
社区活跃度 | 高 | 一般 | 高 | 一般 | 2017年重新开始维护,之前中断5年 |
学习难度 | 中等 | 低 | 高 | 高 | 低 |
文档丰富 | 高 | 一般 | 一般 | 一般 | 高 |
其他 | SpringCloud Bus为我们的应用程序带来更多的管理端点 | 支持降级 | Netflix内部开发集成RPC | IDL定义 | 实践公司比较多 |