
1) Spring Boot使编码变简单
2) Spring Boot使配置变简单
3) Spring Boot使部署变简单
4) Spring Boot使监控变简单
5) Spring Boot的不足。
背景
随着公司一年多的成长,我们已经开发了数十个项目了,后台有JAVA的有PHP的,为了更好地提升开发与管理效率,各技术大牛小牛们时常进行激烈的PK,碰撞出了许许多多爱的火花,比如其中之一:微服务实践
设计
只需要有一套BASE微服务,BASE微服务生成业务系统微服务实例,供各个业务系统调用;业务系统不直接调用BASE,只能调用微服务INSTANCE。
这是运维的问题,让运维去解决,运维使用工具,实际也不算困难,反正执行的都是脚本,不需要手工 *** 作。
单点故障影响全局,我们选择了稳定更重要;另外saas的话,为了应对不同行业,会存在过度设计的嫌疑;私有化更容易。
调用逻辑
设计理念
非模块化,谈不上微服务,比如我们上面的用户微服务、产品微服务、地址微服务等,都需要先模块化,为了更好地落实开发,你可能不得不,边模块化边微服务,模块化的时候要注意,不能有关联查询,包要完全独立,到时候微服务才能拆开。
松耦合表示我们模块之间不直接依赖,无状态,可以单独地为外界提供服务;
强内聚是指,我们虽然要拆分成一个个小的微服务,但是也要考虑某些功能的强关联性,比如一个凳子是由四个脚与一个板组成,我们不能把四个脚与板分开售卖,就没有意义了。
开发
spring-boot :较springmvc更加简约了,springmvc有一大零的配置文件,比如spring-servlet、spring-mybatis、springxml与webxml,这些在spring-boot都不需要了,只需要强大的注解功能即可,boot更合适微服务。
spring-cloud :里面有比较多组件,用于支持微服务,比如spring cloud config统一配置中心,用于多环境的配置文件配置,大家再也不用为多个微服务的开发、测试与生产环境的配置文件管理而发愁了;spring cloud eureka用于服务注册与发现,下面有单独介绍;其它的组件大家可以去官网看看,这里不一一介绍,总之如果JAVA平台,尽量使用spring体系的内容。
我们采用mysql,因为我们是应用多,但数据量单表并不算大,多则不超过百万,mongodb也实验过,开发非常快,也非常灵活,但因为不是关系型数据库,维护成本较高。
RESTFUL :URL的资源与 *** 作解耦,让URL更加符合语义,上百个接口也非常好管理,网上有很多文章讲得非常透彻,这玩意不是特别好理解,要多领悟,在项目中实践,就有矛塞盾开的感觉,这里不做详细介绍。
接口文档swagger :比起传统全手工写接口文档,swagger有统一的输出格式,不管是几个人写的;swagger采用写代码的方式来写接口文档,以前修改了代码,还必须打开wiki手工修改接口文档,现在只需要修改一下代码即可,程序员更愿意修改了,成本更低了,前端与其它调用者不会天天吼着,你这接口咋又变了,新加的字段是啥意思呀。
RocketMQ:一直纠结kafka与rocketMQ,最终选择了RocketMQ
为了性能上面的考虑,尽量使用异步编程,比如注册送优惠券,那么注册成功就可以给用户返回注册成功了,但是送优惠券可以是异步调用的,不阻塞注册的线程。
微服务框架下,日志不可能还分散在各个服务节点上,必须有统一的日志中心。ELK是一个实时日志分析平台,就是将各个服务的日志汇总于日志中心,然后可以按照系统、节点等进行搜索,除上述搜索条件外,我们还在各个微服务实现了按照业务id(一次请求生成一个业务id)与用户id搜索日志,方便跟踪与定位问题。
当然可能有更加轻量级与好用的disconf或spring cloud config,但是我们有php开发的应用,以上二者都不支持。如果全是JAVA应用,采用disconf还是非常不错的。
测试
每个程序员都有这样的经历,刚上线,客户又反馈了bug,原来是我们修改某个功能代码的时候,导致了其它功能的bug,每次上线心里都没底;这就体现了接口测试的必须性,尤其是每次版本升级的时候,都需要执行一遍,以防修改某个接口导致其它接口报错,比手动测试靠谱许多。
部署
docker已经家喻户晓了,这是继虚拟机以后,又一重大变革,将所有的单个微服务都放在docker中,这样你何时何地想部署,直接丢过去就OK了,快到爆。
用几句简单的命令就搞定了负载均衡,而且还可以平滑升级,版本升级的时候,大家就不用告诉客户:系统通知,某日某晚00:00-08:00我行处于系统升级维护中,大家不要去取钱哦,因为你可能取不出来,呵呵。
升级
我们采用工具flyway,可以对数据库脚本进行版本控制。
传统的版本升级,
1开发推代码并同时记录自己提交了哪些文件;
2项目经理根据svn审核文件,并打包成war包;
3投到测试环境让测试公司测试;
4中途修改了文件,可能需要重新打包;
…
我都写不下去了,项目经理像个超人似的。
现在用持续集成(CI)非常简单,我们用的工具是Jenkins,推完代码,点几下按钮就完成了上线,不管是测试环境,还是生产环境都非常简单,不然项目经理核对文件眼睛都绿了。
结尾
本文主要是介绍微服务开发上的选型,对于细则不做深究,大家感兴趣可以了解下各个组件。当然,我们的选型未免正确,不同场景应用可能完全不同,本文仅供参考。
由于微服务数量太多导致维护成本巨大,服务治理就是来解决这个问题。服务治理就是让服务子维护,微服务做为服务提供方主动向服务治理中心注册,服务的消费者通过服务治理中心查询需要的服务并调用,如下图:
springcloud通过对Eureka的二次封装来实现服务治理。Eureka提供了服务端和客户端,服务端是服务注册中心,客户端完成服务的注册和发现,其关系如下:
Eureka的架构:
注:1微服务A向Eureka Server注册,并通过心跳机制告诉Server自己的状态。如果微服务A需要下线也要告诉Server;如果一段时间Server没有收到微服务A的心跳,那么认为微服务A已经宕机
2微服务B从Server中发现微服务A,然后向微服务A发起请求
3Server 有多个节点,一旦一个节点宕机,还能用其他的Server
1创建springboot工程 ,并选择Eureka Server
2 在启动类上加注解 @EnableEurekaServer
3增加applicationyml配置文件
4启动2台eureka server ,将自己注册到对方
spring-boot:run -Dport=6868 -Deurekaserver=>
本文将从 Tomcat性能优化,SpringCloud开启重试机制,Zuul网关性能参数优化,Ribbon性能参数优化,Feign与Hystrix性能优化等 五个方面分享在生产环境如何做好SpringCloud性能优化。
一般基于SpringCloud的微服务能够脱离传统的tomcat,独立跑起来,SpringBoot功不可没,其原理是SpringBoot内嵌了tomcat(当然可以换成其他servlet容器,如jetty),能够以java -jar形式就能跑起来。
所以针对每个springboot服务,我们需要对tomcat的一些参数进行优化,以下是楼主项目组优化的tomcat参数配置,供大家参考。
tomcat参数说明:
maxThreads,acceptCount参数应用场景
场景一
场景二
场景三
maxThreads调优
一般说服务器性能要从两个方面说起:
1、cpu计算型指标
2、io密集型指标
所以大部分情况下,tomcat处理io型请求比较多,比如常见的连数据库查询数据进行接口调用。
另外,要考虑tomcat的并发请求量大的情况下,对于服务器系统参数优化,如虚拟机内存设置和linux的open file限制。
maxThreads设置多大合适?
我们知道线程过多,会导致cpu在线程切换时消耗的时间随着线程数量的增加越来越大;线程太少,服务器的请求响应吞吐量会急剧下降,所以maxThreads的配置绝对不是越大越好。
实际情况是设置maxThreads大小没有最优解,要根据具体的服务器配置,实际的应用场景不断的调整和优化。
acceptCount设置多大合适?
尽量与maxThreads的大小保持一致 , 这个值应该是主要根据应用的访问峰值与平均值来权衡配置的。
当使用URL进行路由时,则需要对zuulhostconnect-timeout-millis和zuulhostsocket-timeout-millis参数控制超时时间。
请求连接的超时时间
请求处理的超时时间
对所有 *** 作请求都进行重试
对当前实例的重试次数,针对同一个服务实例,最大重试次数(不包括首次调用)
对下个实例的重试次数,针同其它的服务实例,最大重试次数(不包括首次server)
注意Hystrix断路器的超时时间需要大于ribbon的超时时间,不然不会触发重试
Feign和Ribbon在整合了Hystrix后,首次调用失败的问题?
目前楼主的强烈做法是: 禁用Hystrix的超时时间,设为false
还有一种是官方提倡的是 设置超时时间。
在实际的项目中亲测,这种方式也有不好的地方, 如请求时间超过5s会出现请求数据时有时无的情况 ,给用户的感觉是 系统不稳定,要求整改 。
另外,禁用hystrix,官方不推荐 。
hystrix超时设置原则
问题:一个> 《一步一步学SpringBoot2微服务项目实战》百度网盘pdf最新全集下载: zy9k 简介:本书以项目实战为主体,循序渐进地介绍了Spring Boot 20在Web应用开发方面的各项技能。第1章由零开始引导读者快速搭建Spring Boot开发环境,对之后Spring Boot的探险之旅奠定基础。第2章、第3章、第10章和第13章介绍Spring Boot数据访问应用,整合众多流行技术Spring Boot集成Druid、Spring Data JPA和MyBatis,快速访问MySQL和Mongo DB数据库。第4~6章重点介绍Spring Boot集成Thymeleaf模板引擎、事务使用以及拦截器和监听器的应用。 目录: Spring Boot Admin 用于管理和监控一个或者多个Spring Boot应用, Spring Boot Admin 分为Server端和Client端,Client通过> 以上就是关于为什么选择Spring Boot作为微服务的入门级微框架全部的内容,包括:为什么选择Spring Boot作为微服务的入门级微框架、微服务架构实践 - 你只懂docker与spring boot就够了吗、springboot-服务治理等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力! 欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)