『互联网架构』软件架构-微服务介绍及Eureka服务注册与发现（91）

正式开始springcloud，之前说的springboot很简单，为什么只说使用不讲原理，真的springboot没啥好讲的。说到springcloud首先得说微服务。

（一）传统单体架构介绍及优缺点

在传统的项目，在10年之前陈奕迅【十年】，会有一个tomcat，这个tomcat里面就放一个war包，war包中包括多个模块【商品，订单，用户，库存，支付】所有的都放在一个项目中，这就是单体架构。而且所有的模块都访问一个DB。慢慢的数据库会变成读写分离，但是垂直方向都是单一的。读和写都有一个，没有从模块角度进行拆分，这个优缺点之前也说过。

一个项目包（war包，归档包）包含了应用的所有功能, 在没有出现微服务概念之前，基本上都是这种架构形式存在， 我们一般把程序打包成一个文件后，扔到tomcat或者jetty， jboss等应用服务器中。

• 特点

1. 部署很简单，符合我们的思维
2. 项目臃肿（从一行变成了百万行，修改代码需要重启服务，重启服务就需要断业务。）
3. 技术债务（一个项目跑多年，经历了多个程序员，前面的需求代码都没有注释。新来的开发人员对业务不熟悉，代码也没注释，所以新入职的 程序员 都愿意进去新项目组，新的项目都是新业务，这就是经常跳槽和不经常跳槽的人可以避免这些坑）
4. 部署频率低（项目庞大，该bug的时间可能还没项目发布的时间长，一两个bug，不允许更新的，更新的东西太少了。迭代多个需求和很多个bug后，找个黄道吉日去更新，你的更新频率就低了）
5. 扩展性差（改一个模块千万整个项目，举个例子：项目都用到缓存了，缓存和项目在一起的，如果修改缓存整个项目都有问题。）
6. 阻碍技术创新（传统项目单体架构整个项目只有一个包，这个包里面所有的模块都使用同一套技术，如果发现市面上某个框架和技术非常nice，至少可以解决某一块的性能问题，根本问题，想引入发现非常的困难。举个例子：原来用struts，感觉spring mvc很好，整个全部都改，肯定不敢去改）

（二）单体架构到微服务架构的改造及优缺点

把每个独立的模块单独抽出来作为一个独立运行的服务，服务之间采用轻量级Rest方式调用。

*微服务特点

1. 每个小组专注于一个微型服务，致力于该服务的稳定性，可用性，服务性能，以及业务的迭代开发。

2. 每个微服务可以独立运行（独立一个进程运行） 。

3. 多个微服务或者说一系列微服务组合起来就构建了一个或者多个独立的系统 。

4. 每个微服务只针对独立的业务开发基础的服务，也就是说一个微服务只关注某个特定的功能。

5. 每个微服务可以使用不同的技术实现，以及每个微服务有自己独立的数据库。

6. 每个微服务之间通过一些轻量的通讯机制进行通讯，例如REST API 更加容易部署，而且可以全自动部署。

• 单体架构到微服务架构改造问题

1. 运维要求高（原來1个war包发布很容易一个war包丢进去就可以了，现在拆成了N个war包，部署的时候需要部署多个，查看日志的时候也需要链路查询比较麻烦）
2. 分布式固有的复杂性
3. 接口调用成本高

（三）微服务设计原则

1. 单一职责。
2. 服务自治。
3. 轻量级通讯原则。
4. 接口明确原则。
5. 微服务粒度（服务层原则，服务给谁）。
6. 服务依赖（不要形成回环）。

（四）微服务与SOA联系及区别

1. SOA(面向服务架构)是集成多个较大组件（一般是应用）的一种机制，它们将整体构成一个彼此协作的套件,是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯。
2. 微服务架构中，业务逻辑被拆分成一系列小而松散耦合的分布式组件，共同构成了较大的应用，每个组件都被称为微服务。

（五）基于Springboot的微服务架构的改造

用户微服务

订单微服务

调用流程：客户端>订单微服务>用户微服务

• 当用户微服务有多台实例提供高可用服务或者负载均衡服务的时候，订单微服务怎么来调用用户微服务呢？同时怎么支持服务动态水平增加或者减少呢？

  1.Nginx

2.服务发现

（六）服务注册与发现组件Eureka架构介绍

Eureka是Netflix开发的服务发现框架，本身是一个基于REST的服务，主要用于定位运行在AWS域中的中间层服务，以达到负载均衡和中间层服务故障转移的目的。SpringCloud将它集成在其子项目spring-cloud-netflix中，以实现SpringCloud的服务发现功能。

• 作为服务注册中心，Eureka比Zookeeper好在哪里
  

  著名的CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。在此Zookeeper保证的是CP, 而Eureka则是AP。

• Zookeeper保证CP
  

  当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

• Eureka保证AP
  

  Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

  1.Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务 

  2.Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用) 

  3.当网络稳定时，当前实例新的注册信息会被同步到其它节点中

因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。

• 基本原理

• 处于不同节点的eureka通过Replicate进行数据同步
• Application Service为服务提供者
• Application Client为服务消费者
• Make Remote Call完成一次服务调用

服务启动后向Eureka注册，Eureka Server会将注册信息向其他Eureka Server进行同步，当服务消费者要调用服务提供者，则向服务注册中心获取服务提供者地址，然后会将服务提供者地址缓存在本地，下次再调用时，则直接从本地缓存中取，完成一次调用。

当服务注册中心Eureka Server检测到服务提供者因为宕机、网络原因不可用时，则在服务注册中心将服务置为DOWN状态，并把当前服务提供者状态向订阅者发布，订阅过的服务消费者更新本地缓存。

服务提供者在启动后，周期性（默认30秒）向Eureka Server发送心跳，以证明当前服务是可用状态。Eureka Server在一定的时间（默认90秒）未收到客户端的心跳，则认为服务宕机，注销该实例。

PS：就说到这里下次说下Eureka配置。

已是最新文章