SpringCloud微服务之一：微服务的起步

谈到微服务，我们先来见见它的面试题：

常见面试题

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	Google	FaceBook
社区活跃度	高	一般	高	一般	2017年重新开始维护，之前中断5年
学习难度	中等	低	高	高	低
文档丰富	高	一般	一般	一般	高
其他	SpringCloud Bus为我们的应用程序带来更多的管理端点	支持降级	Netflix内部开发集成RPC	IDL定义	实践公司比较多