微服务的前世今生

1.一体化架构的优缺点

拿商城系统举例，在项目启动时，我们希望快速的看到成效，以便投产看看市场效果，快速完成验证，所以功能模块都会放在一起，便于开发、发布、测试。

一体化架构带带来的优点就是：

1.代码集中管理、开发直接迭代迅速

2.只需要维护一个项目，运维成本降低

3.排查问题比较方便，只需要看着一个服务就行了

但是一体化架构随着项目越来越复杂、开发人员越来越多，问题就会出现：

1.代码都在一起，发布需要排队，延长交付时间

2.一个修改出现问题，可能影响整个系统

2.使用微服务去解决这些痛点

对服务根据业务模块进行拆分，将业务代码DB，都横向拆分，各个服务维护自己的DB与业务模块，然后再公共的模块抽出来形成一个独立的模块

1.每一个服务的功能内聚，维护人员职责明确

2.服务新功能不影响其他服务，一单服务出现问题，通过熔断降级减少对其他服务的影响

3.微服务化带来的问题

1.服务那么多，我怎么知道哪些服务可以使用？(服务注册发现)

2.原本一个程序内的调用，变成了服务间调用，那么会不会增加整体响应时间？(RPC调用性能)

3.如果出现异常，如何快速排查问题出现在哪个服务？(全链路追踪)

4.RPC框架

原本在一体式架构的服务，一个下单，原本需要经过用户、订单、支付模块，都在一个服务里面，现在需要调用3个服务。如果每调一个服务，网络耗时30ms，那么整体时间就要增加30 * 3 – 30 = 60ms。

所以服务之间的RPC调用耗时，将是影响整体性能的一个重要因素，所以如何选择一个合适的RPC框架在设计中显得至关重要，RPC技术主要分2块，传输、序列化。

4.1.传输协议(通信方式)

传输主要是为了提升网络性能，即选择合理的IO模型，常见的模型有5个：同步阻塞 I/O、同步非阻塞 I/O、同步多路 I/O 、复用信号驱动 I/O、异步 I/O，这里有一篇文章说的很清楚，可以用作参考：Linux IO模式及 select、poll、epoll详解

同步阻塞就是例如http、NIO异步通信dubbo

4.2.序列化协议

5.注册中心

老的系统，我们使用nginx进行反向代理，一个服务有哪些机器可以用，可以查看nginx 的配置知道，这其实也是一个服务发现的过程，但是nginx配置固定，无法动态修改。为了让服务发现过程更加的灵活，就要使用到注册中心

5.1.客户端嵌入式代理(Eureka +Ribbon)

我们常见的注册中心ZooKeeper、Eureka，这些注册中心主要有2个功能，1提供了服务地址的存储，2存储发生变化后，将变化的推送给客户端。

如何检测服务是否客观下线呢？通常采用心跳模式，注册的服务每隔一段时间，发送心跳包给注册中心，注册中心定时轮训节点，将超时失效的节点下线。

如何做负债均衡呢？客户端(消费者)每次从注册中心获取服务列表，然后根据自己的负债均衡策略请哪一个服务，例如Spring Cloud中Eureka +Ribbon

5.2.主机独立进程代理(Service Mesh)

主机独立代理模式和客户端模式类似，只是将发现服务和负债均衡的能力抽象到一个独立的代理进程去做了，一台机器一个这样的进程去维护节点信息，然后客户端(消费者)获取服务直接找代理回去就行，代理会做负债均衡。Service Mesh就是主机模式，将网络中的机器分割成若干网格，每个网格一台机器，一台机器里面若干个服务。

6.分布式trace

如果我们是一体式服务，出现问题，只需要看一个日志就行了，并且日志是一个流，可以看出上下文来。

但现在分部署微服务中，每个服务日志都是独立的，如果出了问题，我们如何能快速的找到问题出在哪个服务呢？

我们通常会在rpc调用的时候带上一个traceid，这样就可以把请求串起来，如果出现请求的分支，那么可以加一个spanid去做