在微服务练习过程中遇到的问题

微服务架构的基础构建

• 首先构建微服务的时候，我们先新建了一个Microservices的Maven工程，在其下新建了我们所使用的工程。当我们建立新的工程时发现子工程和父工程的位置是乱的，所以，为了避免自己混淆以及便于使用，首先将父工程的src资源文件夹删除。
• 再看pom文件，当我们在父工程下建立新的工程时，我们会发现双方的pom文件就回发生变化：

Microservices的pom文件：

	<groupId>com.zpark</groupId>
    <artifactId>Microservices</artifactId>
    <packaging>pom</packaging>
    <version>1.0-SNAPSHOT</version>
    <modules>
        <module>common</module>
        <module>consumer</module>
        <module>service</module>
        <module>eureka</module>
    </modules>

common的pom文件：（其他子工程不做展示）

	<parent>
        <artifactId>Microservices</artifactId>
        <groupId>com.zpark</groupId>
        <version>1.0-SNAPSHOT</version>
    </parent>
    <modelVersion>4.0.0</modelVersion>

    <artifactId>common</artifactId>

在构建工程时关系已经建立，我们所要做的就是将各自所需要的依赖插入。

1. 关于通用mapper启动器

引入原因： 原生Mybatis需要编写大量的mapper.xml文件需要编写大量的sql语句，使用繁琐。通用mapper的引入极大的简化了打码量。
代码参考： 关于微服务的实例练习中的代码

• pom文件引入依赖

		<dependency>
            <groupId>tk.mybatis</groupId>
            <artifactId>mapper-spring-boot-starter</artifactId>
        </dependency>

• yml配置信息

mybatis:
  type-aliases-package: com.zpark.model
  configuration:
    map-underscore-to-camel-case: true

• 具体使用的注意点
  实体类： 类名与数据库中表名一致时可直接使用，不一致时通过注解指明@Entity @Table(name = “表名”)
  mapper接口： extends Mapper <实体类>，继承了Mapper接口后，此时就有了针对实体类的大量方法
  service接口： 定义自己所要实现的抽象方法
  service实现类： 通过@Service注解指明service，该类实现service接口，方法使用mapper接口中提供的方法

2. 关于Eureka注册中心

具体代码参考：关于微服务的实例练习中的代码

引入原因： 在现在日益复杂的互联网环境，一个项目肯定会拆分出众多微服务。此时如果还人为管理地址，不仅开发困难，将来测试、 发布上线都会非常麻烦，所以引入Eureka注册中心对服务进行管理。此时服务调用者无需自己寻找服务，而是把自己的需求告诉Eureka，然后Eureka会把符合你需求的服务告诉你。（最好的案例就是滴滴）

• 原理图：
  
  解释：
  Eureka：服务注册中心（可以是一个集群），对外暴露自己的地址
  service：启动后向Eureka注册自己信息（地址，提供什么服务）
  consumer：向Eureka订阅服务，Eureka会将对应服务的所有提供者地址列表发送给消费者，并且定期更新
  心跳(续约)：提供者定期通过http方式向Eureka刷新自己的状态

3. 高可用的Eureka Server

添加高可用Eureka注册中心代码参考： 关于微服务的实例练习中的代码

解释： 所谓的高可用注册中心，其实就是把EurekaServer自己也作为一个服务进行注册，这样多个EurekaServer之间就能 互相发现对方，从而形成集群。

1、service补充:

• 服务续约：
  在注册服务完成以后，服务提供者会维持一个心跳（定时向EurekaServer发起Rest请求），告诉EurekaServer：“我还活着”。这个我们称为服务的续约（renew）；

eureka:
  instance:
      lease-expiration-duration-in-seconds: 90 #服务失效时间，默认值90秒
      lease-renewal-interval-in-seconds: 30 # 服务续约(renew)的间隔，默认为30秒

• 修改instance-id：
  默认格式是： ${hostname} + ${spring.application.name} + ${server.port}
  instance-id是区分同一服务的不同实例的唯一标准，因此不能重复

eureka:
  instance:
      instance-id: ${spring.application.name}:${server.port}

2、consumer补充：

• 获取服务列表：
  当服务消费者启动是，会检测 eureka.client.fetch-registry=true 参数的值，如果为true，则会从Eureka Server服务的列表只读备份，然后缓存在本地。并且默认每隔30秒会重新获取并更新数据。

eureka:
  client:
      registry-fetch-interval-seconds: 5 #每隔5秒向Eureka拉取一次新的服务提供方的列表

3、自我保护
我们关停一个服务，就会在Eureka面板看到一条警告：

解释： 这是触发了Eureka的自我保护机制。当一个服务未按时进行心跳续约时，Eureka会统计近15分钟心跳失败的服务 实例的比例是否超过了85%。在生产环境下，因为网络延迟等原因，心跳失败实例的比例很有可能超标，但是此时就 把服务剔除列表并不妥当，因为服务可能没有宕机。Eureka就会把当前实例的注册信息保护起来，不予剔除。生产 环境下这很有效，保证了大多数服务依然可用。
但是这给我们的开发带来了麻烦， 因此开发阶段我们都会关闭自我保护模式：

eureka:
  server:
      enable-self-preservation: false # 关闭自我保护模式（缺省为打开）
      eviction-interval-timer-in-ms: 1000 # 扫描失效服务的间隔时间（缺省为60*1000ms）