IHai-MicroService

之前说要写点东西和大家共同学习微服务的东西，一晃3个月过去了，中间有出差2个月，但最重要的还是自己以前没有写东西的习惯，这里给大家道歉了，下边我将努力坚持把这个事情做下去。

一、简介

当今的IT世界中AI、区块链、微服务无人不知无人不谈，对于AI及区块链本人比较感兴趣但由于本职工作与其尚无交集，通过各位大牛专家们的宣传大概能理解其理论价值，但如何实际落地就完全没有头绪了；而在自己的工作中从14年开始接触微服务，所以在这里想跟大家分享一下自己对微服务的理解历程，以及自己未来一段时间内想要在微服务方面做的一些努力。

在此我不准备对微服务下一个定义，这个事情已经有很多人做了，而每个人的理解也都有所不同；我也不会去强调微服务和传统的单体应用相比谁更好，因为不同场景中各有优劣势，而且每个决策者的关注点也不同。

在此我将介绍自己对微服务的一些理解，以及在未来一段时间内希望通过IHai-MicroService整个微服务框架来实践自己的理解，此框架中部分组件将使用开源组件，部分组件将按照自己的理解造些新轮子。对于使用的开源组件部分有些会对比多个组件进行选择，有些则Just use it，如果非要有个理由的话，可能会是我乐意（开玩笑了，在网络中评价差不多的情况下会挑选自己比较熟悉的），在IHai-MicroService的研发过程中，针对各个组件可能会先做一些相关技术或概念的衍生项目，如注册中心集群同步牵扯到数据同步及网络编程，因此会用Netty做一个简单的HTTPProxy进行网络编程验证，会做一个简单的同步算法示例进行注册中心集群数据同步的算法验证，对于这些内容也将和大家分享。

二、微服务组成

注册中心

对服务提供方信息进行注册，供服务治理及服务消费方发现使用；而对于服务注册方式存在两种模式：

1、接口级，其将服务提供方应用名以及自身提供的服务接口同时注册到注册中心，服务消费方不需要关心服务接口由谁提供，只需要关注自己需要使用什么服务接口。

优点：

a、便于服务治理-通过注册中心即可方便的获取所有接口信息

缺点：

a、不同服务不可以定义相同名称但实现不同的接口，由于服务消费方调用接口时只使用接口名，会造成混乱

2、服务级，仅将服务提供方应用名注册到注册中心，服务消费方需要知道并维护服务接口与服务应用的映射关系。

优点：

a、不同服务可以定义相同名称但实现不同的接口，由于服务消费方调用接口时需要携带服务提供方应用名，不会造成混乱

缺点：

a、不便于服务治理

在此，我推荐使用Eureka作为微服务的注册中心，理由嘛，网络上已经有很多对比Zookeeper和Eureka的帖子或博文，这里不再重复，给出一个连接供大家查看（ https://blog.youkuaiyun.com/whereismatrix/article/details/53305045）。但同时不推荐按照Spring Boot默认方式使用Eureka，即服务提供方仅将application name作为service id注册到eureka，服务消费方需要在调用接口时需要知道接口是哪个服务提供方提供的。而我认为在微服务架构中服务消费方并不需要知道接口是谁提供的，只需要知道自己想要调用什么接口达到什么目的就好。因此在使用Eureka作为注册中心时，将接口信息放入metadata一并注册到Eureka，服务消费方从Eureka拉取到metadata信息，通过接口查找serviceId后再发起调用。

在IHai-MicroService中，注册中心将使用Netty自己实现，暂定将支持以下基本能力：

1、接口级服务注册发现

服务提供方注册服务

服务消费方发现服务

2、单实例/集群模式

可部署单个节点或以集群模式部署多个节点

3、集群自动同步

集群模式下不同节点间注册信息自动同步

4、集群自动发现

集群模式下，客户端可通过集群中任意一个节点自动发现集群中全部节点

    为了验证学习Netty的能力，做了一个简单的HttpProxy（ihai-http-proxy）服务，感兴趣的同学可以看一下，点这里。

配置中心

管理平台

自动干预

人工干预

监控中心

网关

鉴权中心

服务

服务自治

轻量化