微服务概述

微服务概述

什么是微服务

• 目前的微服务并没有一个统一的标准，一般是以业务来划分
• 将传统的一站式应用，拆分成一个个的服务，彻底去耦合，一个微服务就是单功能业务，只做一件事。
• 与微服务相对的叫巨石

微服务与微服务架构

• 微服务是一种架构模式或者一种架构风格，提倡将单一应用程序划分成一组小的服务==独立部署==，服务之间相互配合、相互协调，每个服务运行于自己的==进程==中。
• 服务与服务间采用轻量级通讯，如HTTP的RESTful API等
• 避免统一的、集中式的服务管理机制

微服务的优缺点

优点

1. 每个服务足够内聚，足够小，比较容易聚焦
2. 开发简单且效率高，一个服务只做一件事情
3. 开发团队小，一般2-5人足以（当然按实际为准）
4. 微服务是松耦合的，无论开发还是部署都可以独立完成
5. 微服务能用不同的语言开发
6. 易于和第三方集成，微服务允许容易且灵活的自动集成部署（持续集成工具有Jenkins,Hudson,bamboo等）
7. 微服务易于被开发人员理解，修改和维护，这样可以使小团队更加关注自己的工作成果，而无需一定要通过合作才能体现价值
8. 微服务允许你融合最新的技术
9. ==微服务只是业务逻辑的代码，不会和HTML,CSS或其他界面组件融合==。
10. ==每个微服务都可以有自己的存储能力，数据库可自有也可以统一，十分灵活==。

缺点

1. 开发人员要处理分布式系统的复杂性
2. 多服务运维难度，随着服务的增加，运维的压力也会增大
3. 依赖系统部署
4. 服务间通讯的成本
5. 数据的一致性
6. 系统集成测试
7. 性能监控的难度

微服务的技术栈

微服务条目	落地技术
服务开发	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作为微服务架构

选型依据

1. 整体解决方案和框架的成熟度
2. 社区热度
3. 可维护性
4. 学习曲线

当前各大IT公司的微服务架构

1. 阿里Dubbo/HSF
2. 京东JSF
3. 新浪Motan
4. 当当DubboX

各微服务的框架对比

功能点/服务框架	Netflix/SpringCloud	Motan	gRPC	Thrift	Dubbo/DubboX
功能定位	完整的微服务架构	RPC框架，但整合了ZK或Consul，实现集群环境的基本服务注册/发现	RPC框架	RPC框架	服务框架
支持Rest	是，Ribbon支持多种可插拔的序列化选择	否	否	否	否
支持RPC	否	是	是	是	是
支持多语言	是（Rest形式）	否	是	是	否
服务注册/发现	是（Eureka） Eureka服务注册表，Karyon服务端框架支持服务自注册和健康检查	是（zookeeper/consul）	否	否	是
负载均衡	是（服务端zuul+客户端Ribbon） zuul-服务，动态路由 云端负载均衡 Eureka（针对中间层服务器）	是（客户端）	否	否	是（客户端）
配置服务	Netflix Archaius SpringCloud Config Server集中配置	是（zookeeper提供）	否	否	否
服务调用链监控	是（zuul） Zuul提供边缘服务，API网关	否	否	否	否
高可用/容错	是（服务端Hystrix+客户端Ribbon）	是（客户端）	否	否	是（客户端）
典型应用案例	Netflix	Sina	Google	Facebook
社区活跃度	高	一般	高	一般	2017年7月才重启
学习难度	中等	一般	高	一般	低
文档丰富度	高	一般	一般	一般	高
其他	Spring Cloud Bus为我们应用程序带来了更多管理端点	支持降级	Netflix内部在开发集成gRPC	IDL定义	实践公司比较多