“这是我参与8月更文挑战的第18天，活动详情查看：8月更文挑战”
1.单体应用
我们常用的都是基于 IDEA的,单体应用,
单体应用的痛点:
单块系统的在上线测试的时候,我们将项目
1.解决冲突
2.测试上线(回归测试)
3.在创建出新的功能--->可能对之前那的代码版本进行测试,
代码冲突--合并--全量功能的回归测试,耗费时间很多,
4.小组之间协作困难,测试服务器比较少,效率低下;
五个人左右的,维护一个单体应用,我们可以理解;
还有一个是技术的版本迭代,可能会别人的代码有大的问题;(有风险)
总结: 打卡一天,关于单体应用,只是适用于少数人的维护团队,可能会出现
- 1.频繁的冲突,解决冲突
- 2.开展测试,没更新一个功能,上线之前都要全量测试,
- 3,各个小组之间效率低,耗费时间长,
- 4,想做技术升级,可能对别人代码有潜在的风险
所以,我们引入微服务,一个单独的服务,独立性,独立的功能和,架构升级等,
2.关于国内互联网BAT的微服务的架构技术演进:
微服务架构设计:
-
独立,灵活性增加
-
研发的效率会增加很多
-
低耦合,高内聚自己的方法,
-
测试,上线,以及在调用过程中,增加效率
-
多环境隔离:
测试环境服务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网关自研)
微服务更内聚于自己的功能，耦合性降低了，性能更高， 但是随之我们要考虑多服务互相调用的数据安全，性能，以及可维护性等问题
