微服务的演进之路

1.单体应用

我们常用的都是基于 IDEA 的,单体应用,

单体应用的痛点:

单块系统的在上线测试的时候,我们将项目

1.解决冲突

2.测试上线(回归测试)

3.在创建出新的功能--->可能对之前那的代码版本进行测试,

代码冲突--合并--全量功能的回归测试,耗费时间很多,

4.小组之间协作困难,测试服务器比较少,效率低下;

五个人左右的,维护一个单体应用,我们可以理解;

还有一个是技术的版本迭代,可能会别人的代码有大的问题;(有风险)

总结:打卡一天,关于单体应用,只是适用于少数人的维护团队,可能会出现

• 1.频繁的冲突,解决冲突

• 2.开展测试,没更新一个功能,上线之前都要全量测试,

• 3,各个小组之间效率低,耗费时间长,

• 4,想做技术升级,可能对别人代码有潜在的风险

所以,我们引入微服务,一个单独的服务,独立性,独立的功能和,架构升级等,

2.关于国内互联网 BAT 的微服务的架构技术演进:

微服务架构设计:

1. 独立,灵活性增加

2. 研发的效率会增加很多

3. 低耦合,高内聚自己的方法,

4. 测试,上线,以及在调用过程中,增加效率

5. 多环境隔离:

测试环境服务 A,只能是调用测试环境的服务 B,(不能调用生产环境的,或者是预环境的服务)

注册中心:

相当于服务的地址列表,服务发现和服务注册的作用;

RPC 的框架:远程调用

2.1  微服务中的组成部分:

• 配置中心:各个服务中配置文件,修改,直接生效

• 监控中心: 对比每个服务的,io,磁盘网络,是否服务调用次数,服务是否存在,宕机等

• 链路监控:各个服务之间调用的,链路之间的时间等

• 日志中心: 各个服务中的日志 ,分类存储

• 服务治理:  (服务管控,治理,以及)

一般就是 dubbo+zookeeper; 服务调用和作为一个注册中心

将一个单体的应用,直接拆分成多个服务之后,解决单体的效率,维护等问题,但是国内的互联网大厂都是自研的技术方案,阿里 dubbo,

中小型公司一般使用的是 dubbo+zookeeper 作为基础,实现微服务

3.国外硅谷的微服务架构的发展

netflix,作为 spring cloud,整合到 spring 的社区,Eureka 作为 netflix 推出的注册中心,zool 是一个网关,config 是一个配置中心

分布式事务--->现在很多公司在用阿里开源出来的一些 Redisson,zookeeper

阿里将 dubbo 重启之后,基于 spring cloud 开源,自研出了一套组件,基于 spring cloud 的体系和标准,称为为 spring cloud alibaba 的技术组件;

• 注册中心: nacos --->Eureka

• RPC 框架: dubbo -->feign+ribbon

• 分布式事务: seata -->无

• 限流/熔断/降级 : sentinel -->hystrix

• API 网关: 无-->zuul

卢卡总结

我个人还是比较倾向于:

spring cloud  alibaba 的技术栈(可以报阿里巴巴的大腿,自研,有数据验证)+ 国内开源组件,(apollp,cat)+Prometheus（系统监控）

ELK(日志)+spring Cloud Gateway( nginx +lua,kong, zuul,API 网关自研)

微服务更内聚于自己的功能，耦合性降低了，性能更高，但是随之我们要考虑多服务互相调用的数据安全，性能，以及可维护性等问题