springcloud微服务实战_01_基础知识

1.1 什么是微服务架构

微服务是系统架构上的一种设计风格, 它的主旨是将一个原本独立的系统拆分成多个小型服务,这些小型服务都在各自独立的进程中运行,服务之间通过基于 HTTP 的 RESTful API 进行通信协作. 被拆分的每一个小型服务都围绕着系统中的某一项或一些耦合度较高的业务功能进行构建,并且每一个服务都维护着各种的数据存储,业务开发,自动化测试以及独立部署机制. 由于有了轻量级的通信协作基础,所有这些微服务可以用不同的语言编写.

1.2 与单体架构的区别

在一个项目建设初期,由于业务不是很多,所以我们将这些业务全都放在一个一系统应用中进行开发.但是随着业务的大量聚集,一个简单的系统往往会变得十分臃肿,改动一个小的需求整个系统就需要重新部署上线,并且难以维护.慢慢的我们就将这个大的臃肿的项目拆分开为多个小型系统, 每个系统负责各自领域的业务.这些系统之间相互协调并且独立的开发与部署.由于是独立的部署,我们很容易准确的为每一个服务评估性能容量,通过配合服务间的协作流程也可以更容易的发现系统瓶颈位置,以及给予较为准确的系统性能容量评估.

1.3 如何实施微服务

微服务拆分的问题:

• 运维的新挑战
• 接口的一致性 需要更完善的接口与版本控制,以及更严格的开闭原则.
• 分布式的复杂性 拆分后的各个微服务都是独立部署并且运行独立的各自进程中,它们只能通过通信来进行协作,所以分布式环境的问题都将是微服务架构系统设计时需要考虑的重要因素,比如网络延迟,分布式事务,异步消息等.

目前来说微服务的并没有一个标准的或正式的定义,每个架构师都是根据自身的理解和实际情况来进行设计,并在发展的过程中不断演化与完善. 一个专家提炼出了微服务架构的九大特性:

• 服务组件化
• 按业务组织团队 当决定如何划分微服务时,通常意味着我们要开始对团队进行重新的规划和组织.按照以往的方式,我们往往会从技术的层面将团队划分为多个,比如 DBA团队,运维团队,后端团队,前端团队,设计团队等.若我们继续按照这种方式组织团队来实施微服务架构开发,当有一个服务出现问题需要更改时,哪怕是小的改动,比如给人物描述增加一个字段,这需要从数据存储开始考虑一直到设计和前端.虽然大家改动非常小,但这会引起跨团队的时间耗时和预算审批. 在实施微服务架构时,需要采用不同的团队分割方法.由于每一个微服务都是针对特定的业务的宽栈和全栈实现,即需要数据的持久化存储,又需要负责用户的接口定义等各种跨专业领域的职能.因为面临大型项目的时候,对于微服务团队的拆分需要更加建议按照业务线的方式进行拆分.
• 做 "产品" 的态度 在实施微服务架构的团队中,每个小团队都应该以做产品的方式,对其产品的整个生命周期负责.
• 智能端点与哑管道 在微服务架构中,原本的组件之间通过函数调用的方式进行交互协作改为 RPC 方式的调用,会导致微服务之间的产生繁琐的通信,使得系统表现的更糟,所以我们需要粗粒度的通信协议. 在微服务中我们通常会使用下面两种调用方式:
  1. 第一种, 使用 HTTP 的 RESTful API 或轻量级的消息发送协议,实现信息的传递和服务调用的触发.
  2. 第二种, 通过在轻量级消息总线上传递消息,类似 rabbitmq 等一些提供可靠异步交换的中间件.

在极度强调性能的情况下,有些团队使用了二进制的消息发送协议,比如 protobuf. 及时这样系统仍然会呈现出 "智能端点和哑管道"的特点,这是为在易读性和高效性之间取得平衡.当然大多数 web 应用或企业系统并不需要在这两者之间做出选择,能够给获取易读性就已经是常常大的胜利了!

• 去中心化治理
• 去中心化管理数据 将每个微服务管理其自有的数据库,这就是去中心化管理数据. 但是由于数据存储在不同的数据库实例后,数据一致性也会成为微服务架构中亟(ji)待解决的问题之一. 分布式事务本事实现难度就很大,所以在微服务架构中,我们更强调各个服务之间进行"无事务"调用,而对于数据一致性,只要求数据在最后处理的一致性即可;若果过程发生错误,通过补偿机制来进行处理,使得错误数据能够达到最终一致性.
• 基础设施自动化 微服务架构务必从一开始就构建起"持续交付"平台支撑整个实施过程,该平台需要两大内容,缺一不可:
  1. 自动化测试
  2. 自动化部署
• 容错设计 在微服务架构中,快速检测出故障源并尽可能的自动恢复服务是必须被设计和考虑的.通常,我们都希望在每个服务中实现监控和日志记录的组件,比如服务状态,断路器状态,吞吐量,网络延迟等关键数据的仪表盘.
• 演进式设计

1.4 Spring Cloud 简介

spring cloud 是一个基于 Spring boot 实现的微服务架构开发工具. 它包含了一些子项目:

• spring cloud config: 配置管理工具,支持使用 git 存储配置内容,可以使用它实现应用配置的外部化存储,并支持客户端配置信息刷新,加密/解密配置内容等;
• spring cloud Netflix: 核心组件,对多个 Netflix OSS 开源套件进行整合.
  • eureka: 服务治理组件,包含服务注册中心,服务注册与发现机制的实现.
  • hystrix: 容错管理,实现断路器模式,帮助服务依赖中出现的延迟和故障提供强大的容错能力.
  • ribbon: 客户端负载均衡的协调组件.
  • feign: 基于 ribbon 和 hystrix 的声明式服务调用组件.
  • zuul: 网关组件,提供智能路由,访问过滤等功能.
  • archaius: 外部化配置组件.
• spring cloud bus: 事件,消息总线.用于传播集群中的状态变化或事件,以触发后续的处理,比如动态刷新配置等.
• spring cloud cluster: 针对 zookeeper,redis,hazelcast,consul 的选举算法和通用状态模式的实现.
• spring cloud stream: 通过 redis,rabbit 或 kafka 实现的消息微服务,可以通过简单的声明式模型来发送和接收消息.
• spring cloud sleuth: spring cloud 应用的分布式追踪实现,可以完美整合 zipkin.
• spring cloud starters: spring cloud 的基础组件,它是基于 spring boot 风格项目的基础依赖模块. ...

1.4.1 版本名与版本号

spring cloud 的各个子项目维护着自己的版本号. 因此每一个 spring cloud 版本都会包含多个不同版本的子项目,为了管理每个版本的子项目清单,避免 spring cloud 的版本号与其子项目的版本号相混淆.没有采用版本号的方式,而是通过命名的方式.

这些版本号采用了伦敦地铁站的名字,根据字母表的顺序来对应版本发布的时间顺序,比如最早的 release 版本为 angel, 第二个 release 版本为 brixton...

每个版本都有对应的版本号,比如 ANGEL.SR6, BRIXTON.SR5 中的 SR6,SR5 就是版本号.

当一个版本的 spring cloud 项目的发布内容和积累到临界点或者一个严重 bug 解决可用后,就会发布一个 "service release" 版本,简称 SRX 版本, X 是一个递增的数字.

来源：oschina

链接：https://my.oschina.net/u/4150612/blog/3179415