微服务（Microservices）和服务网格（Service Mesh）架构概念整理

2019独角兽企业重金招聘Python工程师标准>>>

微服务技术栈    

• Spring boot - 微服务的入门级微框架，用来简化 Spring 应用的初始搭建以及开发过程。
• Eureka - 云端服务发现，一个基于 REST 的服务，用于定位服务，以实现云端中间层服务发现和故障转移。选择可用性 A(Availability)，一致性用Zookeeper
• Spring Cloud Config - 配置管理工具包，让你可以把配置放到远程服务器，集中化管理集群配置，目前支持本地存储、Git 以及 Subversion。
• Hystrix - 熔断器，容错管理工具，旨在通过熔断机制控制服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。
• Zuul - Zuul 是在云平台上提供动态路由，监控，弹性，安全等边缘服务的框架。Zuul 相当于是设备和 Netflix 流应用的 Web 网站后端所有请求的前门。
• Spring Cloud Bus - 事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与 Spring Cloud Config 联合实现热部署。（mq）
• Spring Cloud Sleuth - 日志收集工具包，封装了 Dapper 和 log-based 追踪以及 Zipkin 和 HTrace 操作，为 SpringCloud 应用实现了一种分布式追踪解决方案。
• Ribbon - 提供云端负载均衡，有多种负载均衡策略可供选择，可配合服务发现和断路器使用。
• Turbine - Turbine 是聚合服务器发送事件流数据的一个工具，用来监控集群下 hystrix 的 metrics 情况。
• Spring Cloud Stream - Spring 数据流操作开发包，封装了与 Redis、Rabbit、Kafka 等发送接收消息。
• Feign - Feign 是一种声明式、模板化的 HTTP 客户端。
• Spring Cloud OAuth2 - 基于 Spring Security 和 OAuth2 的安全工具包，为你的应用程序添加安全控制。
• ------------------------------------cloud 外技术------------------------------------
• 分布式事务未选方案：
  • 基于MQ消息通知的方式回撤（删除）数据
  • TCC 自定义数据库操作的粒度，使得降低锁冲突、提高吞吐量成为可能。但是侵入强，实现复杂...
  • GTS 出自阿里：性能强，侵入低，兼容强
  • 参考链接：https://www.cnblogs.com/jiangyu666/p/8522547.html
• 日志处理两大生态Splunk和ELK未选方案：
  • ELK：ElasticSearch，Logstash，Kibana的缩写，基于Lucene的开源搜索服务。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。
  • Splunk： Splunk提供一个机器数据的搜索引擎。使用 Splunk 可收集、索引和利用所有应用程序、服务器和设备（物理、虚拟和云中）生成的快速移动型计算机数据 。从一个位置搜索并分析所有实时和历史数据。 使用 Splunk 处理计算机数据，可让您在几分钟内（而不是几个小时或几天）解决问题和调查安全事件。监视您的端对端基础结构，避免服务性能降低或中断。以较低成本满足合规性要求。关联并分析跨越多个系统的复杂事件。获取新层次的运营可见性以及 IT 和业务智能。

服务网格（Service Mesh）

2017 年底，非侵入式的 Service Mesh 技术从萌芽到走向了成熟。

Service Mesh 又译作“服务网格”，作为服务间通信的基础设施层。

如果用一句话来解释什么是 Service Mesh，可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用 Service Mesh 也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如 Spring Cloud、OSS，现在只要交给 Service Mesh 就可以了。

Service Mesh 的来龙去脉：

1. 从最原始的主机之间直接使用网线相连
2. 网络层的出现
3. 集成到应用程序内部的控制流
4. 分解到应用程序外部的控制流
5. 应用程序的中集成服务发现和断路器
6. 出现了专门用于服务发现和断路器的软件包/库，如 Twitter 的 Finagle 和 Facebook 的 Proxygen，这时候还是集成在应用程序内部
7. 出现了专门用于服务发现和断路器的开源软件，如 Netflix OSS、Airbnb 的 synapse 和 nerve
8. 最后作为微服务的中间层 Service Mesh 出现

Service Mesh 有如下几个特点：

• 应用程序间通讯的中间层
• 轻量级网络代理
• 应用程序无感知
• 解耦应用程序的重试/超时、监控、追踪和服务发现

Service Mesh 架构图：

目前流行的 Service Mesh 开源软件有 Linkerd、Envoy 和 Istio，而最近 Buoyant（开源 Linkerd 的公司）又发布了基于 Kubernetes 的 Service Mesh 开源项目 Conduit。

Service Mesh 开源项目简介：

• Linkerd（https://github.com/linkerd/linkerd）：第一代 Service Mesh，2016 年 1 月 15 日首发布，业界第一个 Service Mesh 项目，由 Buoyant 创业小公司开发（前 Twitter 工程师），2017 年 7 月 11 日，宣布和 Istio 集成，成为 Istio 的数据面板。
• Envoy（https://github.com/envoyproxy/envoy）：第一代 Service Mesh，2016 年 9 月 13 日首发布，由 Matt Klein 个人开发（Lyft 工程师），之后默默发展，版本较稳定。
• Istio（https://github.com/istio/istio）：第二代 Service Mesh，2017 年 5 月 24 日首发布，由 Google、IBM 和 Lyft 联合开发，只支持 Kubernetes 平台，2017 年 11 月 30 日发布 0.3 版本，开始支持非 Kubernetes 平台，之后稳定的开发和发布。
• Conduit（https://github.com/runconduit/conduit）：第二代 Service Mesh，2017 年 12 月 5 日首发布，由 Buoyant 公司开发（借鉴 Istio 整体架构，部分进行了优化），对抗 Istio 压力山大，也期待 Buoyant 公司的毅力。
• nginMesh（https://github.com/nginmesh/nginmesh）：2017 年 9 月首发布，由 Nginx 开发，定位是作为 Istio 的服务代理，也就是替代 Envoy，思路跟 Linkerd 之前和 Istio 集成很相似，极度低调，GitHub 上的 star 也只有不到 100。
• Kong（https://github.com/Kong/kong）：比 nginMesh 更加低调，默默发展中。

关于微服务和服务网格的区别，我的一些理解：微服务更像是一个服务之间的生态，专注于服务治理等方面，而服务网格更专注于服务之间的通信，以及和 DevOps 更好的结合。

欢迎加入技术讨论/分享群：340697945       

转载于:https://my.oschina.net/bianxin/blog/2981092