《开源社区的微服务生态体系》由会员分享，可在线阅读，更多相关《开源社区的微服务生态体系（62页珍藏版）》请在金锄头文库上搜索。
1、技术创新，变革未来 开源社区的微服务生态体系 前言 在微服务方兴未艾如火如荼之际， 如何打造合适自己公司实际情况的微服务框架？ 如何实现以微服务微核心的完整的开发生态体系？ 开源社区为此提供了哪些支持？ 面对眼花缭乱的众多技术，该如何抉择？ 发展趋势发展趋势 看看微服务的世界 核心技术 内容：只罗列，不展开 范围：遗漏是必然的 建议：一家之言，仅参考 基础设施 微服务框架 璀璨群星 XNIO Netty Mina Qconf okhttp Dropwizard Jersey SpringMVC SparkFramework SpringHATEOAS gRPC Thrift Hessian K
2、afka ActiveMQNSQ ELK Doozer etcd Consul SmartStack Eureka NSQ Vintage Spotify Zipkin Ribbon Apache HAproxy LVS F5 Archaius Zuul Vamp Dubbo Motan NetflixOSS SpringCloud Spring CloudNetflix Diamond Pinpoint Spring Boot Karyon RabbitMQ CAT Prometheus Grafana zookeeper SkyDNS Disconf Prana HTTP/2 Govern
3、ator Mantl HTrace Serf 第一部分 核心技术 微服务中必然涉及到的部分核心技术，必不可少 每个技术都有很多种实现，各具特色 在目前的开源界，选择众多，可谓繁星璀璨 核心技术 进程间通讯服务注册与发现负载均衡 熔断 故障转移 Failover 失败重试快速失败 Failfast 微服务中的进程间通讯 对比 OSGi Jigsaw 在这点上，微服务和以OSGi、 jigsaw为代表的Java模块化方案 形成鲜明对比 本质差异 在微服务架构中，为了彻底隔绝不同服 务，采用了最坚决的方案，强制要求服 务之间： 通过远程访问方式进行通讯 微服务中通讯的多样性 三种类型 交互对象的数量
4、 一对一，一对多 Rest R P C 定定制制 应答返回的方式 同步，异步 两个维度 两个维度组合的可能性 一对一对一一一对一对多多 同步 Request/Response 异步 NotificationPublish/subscribe Request/Async responsePublish/Async responses 再结合三种类型，现在大家对“多样性”有体会有吧？ 网络类库的选择 如日中天 Netty 由JBOSS提供 最新版本4.1,2016年发布 鲜为人知的 XNIO 来自Redhat 主要服务于自家的undertow 英雄迟暮 Mina 来自Apache 几乎不再有大版本
5、更新 支持Android Okhttp 新兴势力，发展迅猛 支持Android，支持HTTP2 NettyMina xnio okhttp OkhttpXNIO Netty版本的选择 老版本 推荐升级 新项目不要选 主流版本 追求稳定的选择 已废弃版本 切记不要选！ 已上贼船的赶紧下来 最新版本 支持HTTP/2 有需要再上 Netty4.1 Netty5.* Netty4.0.* netty3.* Rest 框架 因为个人原因偏好 RPC 方案，对 REST 方式研究不多。 平时比较大众化的选择是： 服务器端 Spring MVC 客户端用 Jersey Dropwizard Spring
6、MVC Play Framework Jersey Spring HATEOAS Spark Framework RPC方案 业界的 RPC 方案众多，这里只详细介绍三种，分别代表老中新三代RPC框架 Google gRPC Apache ThriftCaucho Hessian Hessian 基于HTTP协议传输的二进制 web service 方案，由 caucho 公司提供 出现的时间比较早 缺点： 1. 效率和 thrift / gRPC 等相比较差，甚至不如REST风格的Jackson 2. 基本停止发展，最后一个大版本 4.0.*发布于2009年，之后只有bugfix版本 3.
7、以今天的眼光看 hessian 的特性，比较陈旧 由于历史原因，还是有不少框架在使用hessian，比如： dubbo 默认采用 hessian2 序列化 微博新开源的 Motan 框架用的 hessian 4.0.38 Thrift Thrift 源于 Facebook，在2007年捐献给 Apache 目前最新版本 0.9.3(发布于 2015-10-06) 业界最经典的 RPC 框架之一 效率极高,使用广泛，成熟稳定 缺点： 1. 项目似乎不再继续演进，看不到未来的路线图 2. 和 gRPC 相比，缺乏对HTTP/2的支持，缺乏对移动设备的支持 3. 底层通讯机制不够理想：唯品会的OSP
8、框架干脆就放弃Thrift 底层通讯实现, 直接基 于 netty4 重写 gRPC 是 google 最新发布的开源 RPC 框架 声称是一个高性能，开源，将移动和HTTP/2放在首位的通用的RPC框架.“ 支持 android 和 iOS 技术栈非常的新：基于HTTP/2, netty4.1, protocol buffer 3.0 堪称新一代 RPC 框架的典范. 缺点： 1. 太新，缺乏实战分享，缺乏文档，社区还不广泛 2. 遇到问题时，google也不容易找到资料 项目开始于2015年2月 1.0正式版本正式发布于2016年8月 怀旧 求稳 最新 怀旧的同学请选择 hessian 求
9、稳的同学请选择 thrift 追新的同学请选择 gRPC RPC的选择(个人建议) 野路子: 自己定制 01 03 网络通讯 可以选择netty，mina等类库 02 协 议 可以选择 HTTP、HTTP2、TCP等 编解码 可以选择 JSON/Proto 2或者3/thrift，甚至XML 04 最关键的 三种方式排列组合，结果五花八门 消息队列 Apache ActiveMQ Apache Kafka RabbitMQNSQ 轻量 重量 高 轻量级使用 选择 RabbitMQ 重量级使用 选择 Apache Kafka 要求非常高，考虑一下 NSQ 消息队列的选择(个人建议) 禁 没有特殊
10、原因,不要选 ActiveMQ Redis 微博 Vintage DNS Spotify SkyDNS DNS by Consul Raft 协议 Consul etcd PAXOS 协议 zookeeper 一致性要求 强一致性 弱一致注册/服务发现 强一致性方案 说说明明编写语编写语言言 Zookeeper来自 Apache，强一致性(CP), 使用 Zab 协议 (基于PAXOS)Java Doozer doozerd 的 Go 语言客户端，强一致性，使用 PAXOS协议。 很多年前就存在的项目，已经停滞很久.(没有特殊理由，不要选择) Go Etcd据说是受 zookeeper 和 D
11、oozer 启发，使用 Raft 协议Go Consul 来自 hashicorp 公司，和 etcd 一样也是基于 Raft 协议 Consul 最大的优势，是提供可以直接使用的成品 Go SmartStack来自 Airbnb，由 Nerve和 Synapse 两个部分组成，依赖zookeeper和haproxyRuby Eureka 来自 Netflix，服务器端和客户端都是用 Java语言编写，因此只能用于Java和基于 JVM的语言 Java Serf采用的是基于 gossip 的 SWIM 协议Go 弱一致性方案 说说明明实现方实现方式式 Vintage 新浪微博内部使用(没有见到
12、开源,可以借鉴思路) 基于 Redis 的轻量级 KV 存储系统 Redis Spotify (DNS)DNS SkyDNSDNS DNS by Consul可以和 Nginx 集成DNS 内建服务注册 服务注册是任何一个服务化/微服务框架的必不可少的部分 很多框架内建了对服务注册的支持 Spring CloudDubbo 支持注册中心扩支持注册中心扩展展 支持多种实现支持多种实现:默认默认zk Motan 支持支持zookeeper 支持支持consul (内部用内部用Vintage) Spring Cloud Consul Spring CloudZookeeper Netflix OSS
13、 Eureka 个人推荐 虽然方案众多，但是对于普通用户的多数情况，建议在下面三个主流方案中选择： Consul EtcdZookeeper client尽量使尽量使用用 Curator ！ Etcd2: rest Etcd3: gRPC,通过 proxy提供rest支持 Java client API 的通知 机制用起来比较难受 软件 Nginx HAproxy Apache LVS 硬件 F5 实现方式 服务器端负载均衡 客户端负载均衡 负载均衡 单独使用 Netflix Ribbon 框架集成 所有框架都内置负载 均衡的实现 最 新 消 息 ：Github即 将开源他们新设计 的负载 均
14、衡系统GLB(Github Load Balancer),值得期待 熔断器 Netflix Hystrix 这是目前找到的唯一的熔断器开源项目 第二部分 工欲善其事必先利其器 在推行微服务时, 一个微服务框架是必须的 无论是自行打造，还是选现成的 下面我们来介绍微服务框架有哪些可选的轮子 微服务框架 Dubbo：一个绕不开的名字 国内 SOA框架 集大成之作 高性能通讯 分布式 服务框架 服务路由 服务注册 与发现 多协议 集成 服务治理 负载均衡 Dubbo：一段辉煌的历史 DUBBO是一个分布式服务框架，致力于提供高性能和透明化的RPC远 程服务调用方案，是阿里巴巴SOA服务化治理方案的核
15、心框架，每天为 2,000+个服务提供3,000,000,000+次访问量支持，并被广泛应用于阿里 巴巴集团的各成员站点。 来自 dubbo 官方的介绍 Dubbo：令人叹息的现状 阿里放弃了 dubbo，内部改为使用 HSF 框架 dubbo 开发团队解散，合并到 HSF 阿里停止对 dubbo 的支持和后续更新 在2012年底之后基本就不再继续，后续也只有极少量的更新 DubboX：延续，但 当当 fork 并推出了 dubbox 支持 REST 风格远程调用，并增加了一些新的特性 DubboX 陆续有一些版本发布，但只是简单修复 最重要的：后续没有任何功能性的发展计划 路，貌似也是走到头
16、了 Dubbo：其兴也勃 其“亡”也忽 2011 开始开源 起于 2.0.7版本 然后，就再没有然后 20122013 频繁更新戛然而止 沉寂 一年内发布了31个 年初发布了一个小版本 小版本，叹为观止！ 2016 沉寂 Dubbo: 总结 01 02 非常好 极富研究价值，即便是在废弃多年后的今天 如果 能一直发展下来，前途不可限量. 03 面对现实 dubbo 已死，在生产上使用时请谨慎(仅代表个人意见) 个人对 dubbo 停止发展深表遗憾：这个项目本来可以成为一 个伟大的项目，尤其在2015年微服务和 docker 盛行之后，本 可以有更大的发挥空间，可惜了 Motan：下一个Dubbo? 高性能 分布式服务 快速开发 高效的RPC Spring 配置方式 高可用 服务发现 SPI 扩展服务治理 负载均衡 2016年8月开源 Motan：初衷 “Dubbo 功能上比较丰富，但当时我们想要一个比较轻量的 RPC 框架
