springcloud学习笔记之微服务概念

• 微服务概念

1. what 微服务是什么

1)、微

 服务代码比较小，业务单一

2)、服务

独立运行在进程中的单元组件

3)、微服务特点：   

1. 按照业务来划分服务，单个服务代码量小，业务单一，易于维护。
2. 微服务都有自己独立的基础组件，例如数据库、缓存等，且运行在独的进程中。
3. 微服务之间的通信是通过HTTP协议或者消息组件，且具有容错能力。
4. 微服务有一套服务治理的解决方案，服务之间不相合，可以随时加入和剔除服务。
5. 单个服务能够集群化部署，并且有负载均衡的能力。
6. 整个微服务系统应该有一个完整的安全机制，包括用户验证、权限验证、资源保护等。
7. 整个微服务系统有链路追踪的能力。
8. 有一套整的实时日志系统。  

4)、微服务的定义：

1. 按照业务进行划分 将每一个不同的业务划分为独立的应用程序
2. 自动化部署 每一个业务模块自动化开发、部署、运维

     但是自动化部署应该不是微服务的特点吧，无论单体架构还是分布式架 构都可以实现自动化的部署，只是微服务的自动化部署耗费的时间更少  微服务很多，单体架构应用只需要部署一个，但是微服务需要进行多次部署，所以集成自动化部署框架很有必要Jekins，因为服务被拆分了，每一个服务部署涉及到的问题会变少（分治法）

1. 每一个服务可以使用不同的语言，存储技术 集群分布式部署
2. 各个业务模块的互相调用使用轻量级的通信机制进行通信
3. 服务的集中化管理（服务监控、扩容、降级 注册中心、监控中心）       zookeeper Eureka Consul
4. 微服务分布式架构下的雪崩效应

使用微服务架构下，各个服务需要相互依赖，如何一个底层服务出现故障，则会导致其他调用他的服务不可用最终导致整个应用不可用（雪崩效应） 所以会出现熔断机制（恢复机制），降级机制

 

1. why  为什么使用微服务

单体架构应用的痛点：

1. 新的代码会影响旧的应用

  所有的业务模块放在同一个项目下，面对新需求的开发可能会

影响原先的旧有逻辑

1. 复杂

业务越来越大，项目会越来越臃肿，对于部署，运维，甚至开发

会耗费更多的资源（人力资源和时间资源）

1. 服务不能灵活部署

网上说单体架构的并发性能有限,这个本人有不同的理解：

单体架构可以通过nignx负载，数据库读写分离，分库分表，缓存等结构实现分布式的单体架构。从而支持高并发处理，这里应该是针对不同的服务不能分别做到动态的扩展比如我的单体应用有 订单模块，登录模块，搜索模块(核心服务)，评价模块，积分模块（非核心服务）如果我以集群的形式将该应用部署到若干台机器上，虽然能解决并发，但是我的核心服务和非核心服务占有相同的资源，我的核心资源接受的QPS会更高，而非核心资源QPS较低， 在部署满足程序运行的集群后，我的非核心服务浪费了一定的资源（比如100台服务的才能支持我们的的核心服务，20台机器就可以很好的支持我们的非核心服务，但是由于是单体应用所有需要部署100台机器，对于非核心服务造成了资源闲置）而是用微服务后每一个服务单独部署，细粒度的保证了资源的合理利用。

1. 技术迁移和新技术使用很困难

  整个应用在进行正常的技术更替的时候 是很困难的甚至不可能（笔者所说的不可能是指整个新技术迁移的成本比推倒重做的成本更高）但是对于微服务情况，不同的服务可以使用不同编程技术，在新增服务的时候可以采用更快更好的技术实现，技术迁移的时候也可以进行服务模块为单位的迁移。

1. Advantages  微服务优势

1. 复杂问题简单化 分治法
2. 服务过大后可以进行拆分 有强大的水平扩展 横向扩展
3. 务与服务松耦合的形式存在

1. Disadvantages 微服务劣势

1. 分布式事务
2. 服务划分（如何划分并没有明确的规则）
3. 服务复杂

二、Cloud 的相关组件

1、Eureka组件

  spring cloud 的注册中心，负责服务注册和服务发现

   分为server 和client

 server端主要是存储注册到Eureka的注册列表

   （包含一系列服务注册的所有服务所在url地址列表）

   client端

  实现向server注册服务，并在调用其它服务的时候 向server端查询服务列表 保存在本地

 主要在所有需要使用注册重负相关服务的消费方存储一份与服务端对应的消费端需要的服务信息

   考虑场景

  服务新增（新服务注册，旧服务的扩容）

服务削减（服务宕机，服务取消）

2、Ribbon组件

  同一个微服务集群部署后 请求该服务具体的负载均衡是由Ribbon组件完成的

3、Fegin组件

   对于远程服务调用 创建相关的接口 和请求方式，使用该组件自动

4、Hystrix组件

    对服务进行熔断，降级等的处理，防止单个服务故障造成的服务雪崩

 对于Fegin 的每一个服务调用 使用一个线程进行处理

5、Zuul组件

  服务网关

  1、将所有的微服务api接口统一聚合在一起，通过网关来为外部提供服务

   2、在网关层可以做一些安全验证， 例如请求是否合法，请求的资源是否允许

   身份认证，权限认证，对内部服务进行保护

   3、实现监控，日志输出，请求记录

6、spring cloud config

       配置文件的统一管理

    当微服务特别多的时候，每一个服务配置信息的处理是很麻烦的一件事情，

所以spring cloud 提供了统一的配置信息的读取和重写功能

7、请求的链路追踪

    对于微服务系统一个请求失败的问题定位，由于每一个微服务系统集群部署，服务之间互相调用，从而导致

追踪和定位问题比较复杂，需要使用链路追踪组件

 google Dapper  阿里的Eagleeye

 

  

三、微服务框架的比较

1. Cloud 与dubbo的比较

微服务关注点	Spring Cloud	dubbo
配置管理	Spring Cloud config	无
服务发现	Eureka Consul zookeeper	zookeeper
负载均衡	Ribbon	自带
链路追踪	Spring Cloud Sleuth	无
容错	Hystrix	不完善
通信方式	http	rpc
安全框架	Spring cloud security	无
网关	Zuul	无