携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第10天，点击查看活动详情
引言
为什么要用微服务？
不能为了追求技术而去用，一个小团队用上微服务后，开发维护成本偏高。
为了学习为了卷，可以快速的去学一遍目前的大趋势技术，这也是写这篇文章的目的。
微服务解决的痛点:
- 服务与服务间的调用
- 多服务间鉴权与资源的处理
- 多项目需要开通服务器多端口的权限
- 负载均衡与高可用，分布式
- 有多大吹多大等
微服务自身的痛点:
- 版本兼容
- 事物处理
- 兼容新员工上手
- 模块解耦
- RPC 服务与服务调用链路过多的时候事物与消息一致性
- 排错链路日志的规范化
鄙人就不一一列举了，这就像我们在讨论什么是最好的语言一样...
微服务名词 - 注册中心
字面意思，其实差不多已经清楚；就相当于一个服务池，我注册一个服务丢进去，你注册一个服务丢进去，同一个池子，后面我们两个服务就能产生更好的交互。
举个栗子:
现在有一个英雄联盟中名为无畏先锋服务器，你在里面注册一个名字为爷傲奈我何的的用户，我注册了一个为名为 PDD的用户，我们就能互相发信息，联机打游戏；反过来，你要是在黑色玫瑰服务器注册，我们就不通了，需要另辟跷径转服了对吧。
目前市面上热门的注册中心：
- Eureka
- Nacos
- Consul
第一名已经凉了，你又要刚我了，人家明明活的好好的，eureka2.0 已经出来，不过就是商业闭源了。初版本开源社区走一波，大家东敲敲西打打弄好了，一转眼人家拿去搞米了，堪比老罗的 PPT。消息来源： github.com/Netflix/eur…
意思就是 2.0 版本我维护一半闭源了，不推荐大家使用。
Nacos 推荐使用，国产，注册中心、服务发现、配置中心一体化，符合国人思想
就是，不用搞那么多弯弯绕，直接合体，我愿称之为最强。
consul 是Spring Cloud 官方的，也可以作为注册与配置中心，不过用起来没 Nacos 方便，也是有一点弯弯绕，果断放弃。
微服务名词 - 服务发现
当服务引用自动发现依赖，并注册到注册中心后，会每隔一会给注册中心发送一个心跳，告诉注册中心自己没有嗝屁。
就像是注册到交换机，主机给交换机发送心跳，交换机处理局域网，让这些电脑能根据 ip 相互访问到。
微服务名词 - 配置中心
抛开微服务不谈，我们用的框架Spring Boot，当然微服务也是基于 Spring Boot。配置文件应该都知道，在 resources 文件下，有一个名为 application 或 application-** ，然后以 yml 或者 properties 结尾的文件。
但我们发现，这个配置文件
- 并不支持动态修改...
- 并且多个项目我还要每个项目，都去配置下
假如微服务中，我们存在 4 个业务性质的服务，且每个服务都存在数据库与缓存或者中间件等等的配置，哦豁，配置地狱。
这个时候我们引入配置中心，像下面这样：
开发和线上有一套环境，统一管理，并且在配置一个魔法功能后，我们还能动态修改某些配置，例如配置的一些固定变量，OSS 的地址，以及我们后面会用到的路由信息。
麻瓜式操作，后面会单独开出一篇文章讲搭建与使用，目前抛开这些东西，我们只做大致了解。
微服务名词 - 负载均衡
众所周知，我们单个服务可以在多个端口进行启动，放在不同的服务器。如图所示：
搭建完这样的结构，注册到注册中心，就可以根据服务名pro-service进行请求，就达到了异地多活，单个服务或服务器挂掉不影响作业。
微服务中我们采用 ribbon 进行负载均衡，ribbon 属于客户端负载均衡，从注册中心拿到服务节点，进行轮询负载均衡。
微服务名词 - 网关
先看图，可以根据请求 url 后缀不同走不同服务：
这样相当于服务器对外只暴露一个端口，或者一个接口都不用暴露，配置 SSL 证书用域名使用 Nginx 进行反向代理。这样买 SSL 证书也只用买一个域名的。
目前热门的网关：
- Gateway （Spring Cloud 亲儿子）
- Zuul
Zuul 凉了...,因为其 1.x 版本性能不好，配置也不简便，2.x 迟迟不推出。导致 Spring Cloud 官方直接舍弃，导致现在 2.x 版本出来后，貌似 Spring Cloud 并没有集成，不过这都不是重点，重点还是在我们要使用 Spring Cloud 亲儿子 Gateway。
