微服务

一 定义

微服务架构是一项在云中部署应用和服务的新技术
可以在"自己的程序"中运行  , 并通过"轻量级设备与HTTP型API进行沟通"
微: 狭义来讲就是体积小 ,  意思就是说单个服务的设计  ,所有参与人从设计 , 开发 , 测试 , 运维所有人加起来只需要2个披萨就够了
服务: 所谓服务 , 一定要区别与系统 , 服务一个或者一组相对较小且独立的功能单元 , 是用户可以感知最小功能集

二 特点

 1 微服务不需要像普通服务那样成为一种独立的功能或者独立的资源

 2 微服务是需要业务能力相匹配

 3 微服务是利用组织的服务投资组合 , 然后基于业务领域功能分解它们 , 在看到服
   务投资组合之前 , 它还是一个业务领域

三 基本思想

在于考虑围绕着业务领域组件来创建应用 , 这些应用可独立地进行开发 , 管理和加速 , 在分散的组件中使用微服务架构和平台 , 部署 , 管理和服务功能交付变得更加简单

四 诞生时间

 出现于2012年 

五 服务平台

开源工作流平台Imixs-Workflow

六 Imixs的微服务

基于Imixs的工作流引擎的复杂功能构建的
它可以以多种不同的方法来控制业务数据
可以发送电子邮件推送消息 , 日志业务交换 , 还可以确保所有类型业务数据的安全

七 工具开发

 Seneca是构建微服务框架的工具

八 微服务风格

是一种使用一套小服务来开发单个应用的方式途径 , 每个服务运行在自己的进程中 , 并使用轻量级机制通信 , 通常是HTTP API , 这些服务基于业务能力构建 , 并能够通过自动化部署机制来独立部署

九 微服务与单体架构区别

1 单体架构带来的问题

  1) 复杂性逐渐变高
  2) 技术债务逐渐上升
  3) 部署速度逐渐变慢
  4) 阻碍技术创新
  5) 无法按需伸缩

2 区别

  1) 耦合度
     单体: 所有的模块全都耦合在一起 , 代码量大 , 维护困难
     微服务: 每个模块就相当于一个单独的项目 , 代码量明显减少 , 遇到问题也相
             对来说比较好解决
  2) 数据库
     单体: 所有的模块都共用一个数据库 , 储存方式比较单一
     微服务: 每个模块都可以使用不同的储存方式 (比如有的用redis , 有的用mysql)
             数据库也是单个模块对应自己的数据库
  3) 开发技术
     单体: 所有模块开发所使用的技术一样
     微服务: 每个模块都可以使用不同的开发技术 , 开发模式更灵活

十 微服务与SOA区别

微服务  , 从本质意义上看 , 还是SOA架构 , 但内涵有所不同 , 微服务并不绑定某种特殊的技术 , 在一个微服务系统中 , 可以有java编写的服务 , 也可以有Python编写的服务 , 它们是靠Restful架构风格统一成一个系统的
微服务本身与具体技术实现无关 , 扩展性强

十一 Restful架构

1 定义

     是一种网络应用程序的设计风格和开发方式 , 基于HTTP , 可以使用XML格式定义或JSON格式定义
     指的是一组架构约束条件和原则 , 满足这些约束条件和原则的应用程序或设计就是restful
     是一种互联网软件架构

2 风格

      一种软件架构风格 , 设计风格 , 而不是标准 , 只是提供了一组设计原则和约束条件 , 它主要用于客户端和服务器交互类的软件
      基于这个风格设计的软件可以更简洁 , 更有层次 , 更易于实现缓存等

十二 微服务本质

   微服务 , 关键其实不仅仅是微服务本身 , 而是系统要提供一套基础的架构 , 这种架构使得微服务可以独立部署 , 运行 , 升级 , 不仅如此 , 这个系统架构还让微服务与微服务之间在结构上"松耦合" , 而在功能上则表现为一个统一的整体
   统一的整体:  1) 统一的风格界面 
                2) 统一的权限管理
                3) 统一的安全策略
                4) 统一的上线过程
                5) 统一的日志和审计方法
                6) 统一的调度方式
                7) 统一的访问入口

十三 目的

   微服务的目的是有效的拆分应用 , 实现敏捷开发和部署

十四 什么项目不适合用微服务

   系统提供的业务是非常底层的 , 如: 操作系统内核 , 存储系统 , 网络系统 , 数据库系统 , 这类系统都偏底层 , 功能和功能之间有着紧密的配合关系 , 如果强制拆分为较小的服务单元 , 会让集成工作量急剧上升 , 并且这种人为的切割无法带来业务上的真正的隔离 , 所以无法做到独立部署和运行 , 也就不适合做成微服务

十五 什么项目适合用微服务

   能不能做成微服务 , 取决于四个要素

1 小

     微服务体积小 , 2披萨团队

2 独

     能够独立的部署和运行

3 轻

     使用轻量级的通信机制和架构

4 松

     微服务之间是松耦合的

十六 微服务拆分原则

   1 是当一块业务不依赖或极少依赖其他服务 
   
   2 有独立的业务语义 

   3 为超过2个的其他服务或客户端提供数据

十七 设计原则

1 单一原则

      每个微服务只需要实现自己的业务逻辑就可以了

2 服务自治原则

     每个微服务从开发 , 测试 , 运维等都是独立的 , 包括存储的数据库也都是独立的 , 自己就有一套完整的流程 , 我们完全可以把它当成一个项目来对待 , 不依赖与其他模块

3 轻量级通信原则

      首先通信的语言非常的轻量
      第二 , 该通信方式需要跨语言 , 跨平台的 , 之所以要跨平台 , 跨语言就是为了让每个微服务都有足够的独立性 , 可以不受技术的钳制

4 接口明确原则

       由于微服务之间可能存在着调用关系 , 为了尽量避免以后由于某个微服务的接口变化而导致其它微服务都做调整 , 在设计之初就要考虑到所有情况
       让接口尽量做的更通用 , 更灵活 , 从而尽量避免其它模块也做调整

十八 特性

   1 每个微服务可独立运行在自己的进程里

   2 一系列独立运行的微服务共同构建起了整个系统

   3 每个服务为独立的业务开发 , 一个微服务一般完成某个特定的功能

   4 微服务之间通过一些轻量级的通信机制进行通信 , 如REST  API或者RPC的方式     
     进行调用

十九 特点

1 易于开发和维护

     由于微服务单个模块就相当于一个项目 , 开发这个模块我们就只需关系这个模块的逻辑即可 , 代码量和逻辑复杂程度都会降低 , 从而易于开发和维护

2 启动较快

     这是相对单个微服务来讲的 , 相比于启动单体架构的整个项目 , 启动某个模块的服务速度明显是要快很多

3 局部修改容易部署

     在开发中发现了一个问题 , 如果是单体架构的话 , 我们就需要重新发布并启动整个项目 , 非常耗时间 , 但微服务则不同 , 那个模块出现了bug我们只需要解决那个模块的bug就可以了 , 解决完bug之后 , 我们只需要重启这个模块的服务即可 , 部署相对简单 , 不必启动整个项目从而大大节约时间

4 技术栈不受限

      比如订单微服务和电影微服务原来都是用java写的 , 现在我们想把电影微服务改成nodeJs技术 , 这是完全可以的

5 按需伸缩

      我们上面说到了单体架构在想扩展某个模块的性能时不得不考虑到其他模块的性能会不会受影响 , 对于我们微服务来讲 , 完全不是问题 , 电影模块通过什么方式来提升性能不必考虑其他模块的情况

二十 缺点

1 运维要求较高

      对于单体架构来讲 , 我们只需要维护好这一个项目就可以了 , 
      但是对于微服务架构而言 , 由于项目是由多个微服务构成的 , 每个模块出现问题都会造成整个项目运行出现异常 , 想要知道是哪个模块造成的问题往往是不容易的 , 因为我们无法一步一步通过debug的方式来跟踪 , 这就对运维人员提出了很高的要求

2 分布式的复杂性

      对于单体架构来讲 , 我们可以不使用分布式 , 
      但是对于微服务架构来讲 , 分布式几乎是必会用的技术 , 由于分布式本身的复杂性 , 导致微服务架构也变得复杂起来

3 接口调整成本高

      比如 , 用微服务是要被订单微服务和电影微服务所调用的 , 一旦用户微服务的接口发生大的变动 , 那么所有依赖它的微服务都要做相应的调整 , 由于微服务可能非常多 , 那么调整接口所造成的成本将会明显提高

4 重复劳动

      对于单体来说 , 如果某段业务被多个模块所共同使用 , 我们便可以抽象成一个工具类 , 被所有模块直接调用
      但是微服务却无法这样做 , 因为这个微服务的工具类是不能被其他微服务所直接调用的 , 从而我们便不得不在每个微服务上都建这个一个工具类 , 从而导致代码的重复

二十一 微服务开发框架

1 Spring Cloud

         http://projects.spring.io/spring-cloud

2 Dubbo

         http：//dubbo.io

3 Dropwizard

         http://www.dropwizard.io
         关注单个微服务的开发

二十二 客户端如何访问这些服务

1 API Gateway

         一般在后台N个服务和UI之间会有一个代理或者叫API  Gateway

2 API Gateway的作用

         1)  提供统一服务入口 , 让微服务对前台透明
         2)  聚合后台的服务 , 节省流量 , 提升性能
         3)  提供安全 , 过滤 , 流控等API管理功能

二十三 微服务之间如何通信

      因为所有的微服务都是独立的java进程跑在独立的虚拟机上 , 所以服务之间的通行就是IPC
      1  REST

      2  RPC

      3  异步消息调用

二十四 这么多微服务怎么查找

       在微服务架构中 , 一般每一个服务都是有多个拷贝 , 来做负载均衡

       1  ZooKeeper
          定义: 注册中心

二十五 微服务挂了怎么办

      1 重试机制

      2 限流

      3 熔断机制

      4 负载均衡

      5 降级

三十六 微服务注册中心

       服务之间需要创建一种服务发现机制 , 用于帮助服务之间相互感知彼此的存在 , 服务启动时会将自身的服务信息注册到注册中心 , 并订阅自己需要消费的服务

1 定义

         注册中心就是服务发现的核心 , 它保存了各个可用服务实例的网络地址

2 功能

         1) 高可用性
         2) 实时更新

3 可用作服务中心的有

         1)  etcd
             高可用 , 分布式 , 强一致性
         2)  consul
             用于discovering和configuring的工具 , 它提供了允许客户端注册和发现
         服务的API
             可以进行服务健康检查 , 以确定服务的可用性
         3)  zookeeper
            在分布式应用中被广泛使用 , 高性能的协调服务

三十七 负载均衡策略

       服务高可用的保证手段 , 为了保证高可用 , 每一个微服务都需要部署多个服务实例来提供服务 , 此时客户端进行服务的负载均衡

1 随机

         把来自网络的请求随机分配给内部中的多个服务器

2 轮询

         每一个来自网络中的请求 , 轮流分配给内部的服务器 , 从1到N然后重新
       开始
         此种负载均衡算法适合服务器组内部的服务器都具有相同的配置并且平均服
       务请求相对均衡的情况

3 加权轮询

         根据服务器的不同处理能力 , 给每个服务器分配不同的权值 , 使其能够接
       受相应权值数的服务请求

4 IP Hash

          这种方式通过生成请求源IP的哈希值 , 并通过这个哈希值来找到正确的真
       实服务器
          这意味着对于同一主机来说它对应的服务器总是相同的