微服务实践

---

2020-03-21

今年年初开始做一个私有化项目，可以撂开历史包袱用点不一样的东西。

我们主要是用了网关和注册中心，项目并不会到一定的规模化，项目未使用到诸如熔断器、配置中心、链路追踪和消息驱动。尽管如此，Eureka、Spring Cloud Gateway、Open Feign 还是提高了不少开发效率。

注册中心

在 Eureka 2.0 版本计划取消后，好多人转投了 Consul ，Consul 确实是一个明智的选择，它不仅具有服务注册发现功能还附带有如动态配置中心、动态化负载均衡功能。好多人不知道的是，Eureka 虽然2.0版计划取消了，但并不代表 Netflix 就停止了 Eureka 的开发和维护，在我们使用 Eureka 的过程当中没有发现明显的问题，它完全胜任了注册中心的工作。

我们的用例很简单就是多个服务发现客户端注册到一个注册中心服务上，这个服务负责了我们服务间的调用寻址和简单的负载均衡（只使用了轮询）。之前服务间调用需要通过提前配置好的命名空间，通过地址解析进行访问，而现在只要在服务中心正确注册，其他服务通过服务名或者ID即可访问，结合负载均衡非常方便进行弹性伸缩。

目前遇到比较明显的问题是重复注册时间较长，比如一个服务重启了，在它再次上线之后会有一小段时间影响其它服务的调用，有可能是我们没有非常详细的处理 Actuator 信息导致的？（给我自己留个小问题）

网关

我们把用户的验证放在了网关处理，外网的请求通过网关转发到具体的服务。Spring Cloud Gateway 用起来似乎没那么友好，如果你不够了解 Spring WebFlux 和 Project Reactor 写起来会有些不顺手，有许多业务问题需要解决，所以并没有把很大精力放在这里。理想情况下，我们可以把不同 router 的不同验签规则都放在网关这里。

公共资源包

由于旧的项目中重度依赖了公共资源包（多个项目共同引用的公共项目），这样导致的问题是：一旦某个公共组件被修改，就会引发连锁反应，多个使用的地方需要同步修改。开始这个项目时我们就刻意的排斥之前的做法，每个项目维护自己的集成组件。但有利就有弊，比如有一个对第三方的访问接口簇（多个接口），如果在三个项目中用到，三个项目就要重复的维护这个接口簇。如果第三方接口修改了规则，则这三个项目就要一个一个全部更改。所以这次的经验是，一刀切并不好，应该分情况而定。

应该放在公共资源包中：

• 请求和响应的Bean（在项目之间集成时不必维护多份）
• 第三方接口簇（设计的时候要尽量“紧凑”，不要做过多的处理，个性化的处理交给各个项目）
• 跨项目资源的状态Bean（比如跨项目资源状态的枚举）

不应该放在公共资源包中：

• 错误响应信息（多数错误信息不会跨项目使用，比如订单的错误信息并不合适资产和下载使用）

协议

如果不依赖某种RPC组件的话，使用 application/json 作为传输协议是一个明智的选择，在各个语言或者框架中都有非常好的支持。但我们没有怎么用，为什么？非技术原因吧。

异步处理

在多个服务的请求中应将相互独立的请求使用异步请求处理，这样可以有效的提高响应速度。但是异步任务的使用当中容易出现问题，并且写起来拖拖拉拉，以至于一直以来我是能不用则不用。不过到了 Java 8+ ， lambda 很多场景可以完美的替换匿名类，CompletableFuture 使用起来很轻松。

分布式事务

如果有分布式事务的支持的话会安全有保障的多，这块内容涉猎的不多，应该多看看在微服务中大家是怎么处理这块问题的。

断路由（熔断器）、舱壁

没用到，一来是没有那么高的并发，另外对于健壮性（反脆弱）没有那么高的要求。