02_国内BAT互联网大厂的微服务架构演进路线

国内BAT互联网大厂的微服务架构演进路线

【一个大系统拆分成很多服务，两三个人维护一个小服务】

拆分成微服务之后，每一个服务都独立的研发、测试、上线、升级、跟其他的服务的关系就不是太大了，每个服务的研发效率都会高很多，系统整体的研发效率也会高很多，他就是微服务架构最大的意义所在。

【拆分之后会遇到单块系统所没有的技术问题，针对这个问题，国内互联网大厂都是从0开始研发了一整套的技术栈】

几乎所有技术组件都是自研，国内最早的微服务架构几乎就是一些互联网大厂自研了一大堆的组件，来支撑拆分成N多服务的大型系统的运行和多人协作开发，包括系统的监控和维护，等等

注册中心、RPC框架、多环境隔离、自动化部署、分布式事务、限流/熔断/降级、配置中心、监控中心、链路监控、日志中心、API网关、安全认证、服务治理

微服务构成

注册中心

【服务A去调用服务B，你不知道服务B在哪个服务器上面，不可能在配置文件上写死吧？让每一个服务都进行一个注册，把自己所在的服务器地址注册上去，其他的服务可以进行服务发现，知道别的服务器地址在哪。】

RPC框架

【不同的服务器怎么进行远程调用呢？RPC框架可以进行远程的调用】

多环境隔离

【服务A在测试环境调用测试环境的服务B，不会调用生产环境的服务B。集成测试环境、功能测试环境、预发布测试环境等。】

自动化部署

【线上部署要纯粹的自动化部署】

分布式事务

【单块系统连接单个数据库，他只要用单个数据库的事务就行了，一个请求需要调用不同的服务器上面的不同的数据库。如果服务A更新了自己的库，服务C失败了，就需要分布式事务】

限流/熔断/降级

【一个服务挂了，其他服务也会连锁式宕机。服务雪崩现象】

配置中心

【不用每个服务更新都去更新配置文件。配置中心修改后，会把配置推送给服务，服务可以立马使用最新的配置】

监控中心

【服务很多，进行监控，业务指标，服务器的硬件情况】

链路监控

【每一个请求都是很多服务串成的一个链路，需要对每一条链路的执行进行一个监控。这条链路耗时多少时间，是否成功等】

日志中心

【每一个微服务都把服务上报到日志中心。在日志中心里对日志进行检索】

服务治理

【会包含之前的很多东西，对这些服务怎么来管控，怎么管理怎么治理。】

API网关

【用户都是发送请求给前端或者客户端，再前后端交互。API网关是屏蔽掉后端所有的服务。减少前端调用的复杂度。API网关会把不同的请求路由给不同的服务。进行微服务和后端的解耦】

安全认证

【安全认证、统一限流等。符合认证才能发现请求】

后来在三五年之前，阿里开源的Dubbo比较流行，在国内基本上把系统拆分为微服务的一些大大小小的公司，用的都是阿里开源的Dubbo，注册中心用ZooKeeper的居多，当时dubbo+zookeeper基本就是一个最原始的微服务技术架构的雏形

至于其他东西，不同的公司可能会找不同的开源项目，但是都没太统一的标准，而且很多公司干脆压根儿就不用其他组件