游客您好
第三方账号登陆
  • 点击联系客服

    在线时间:8:00-16:00

    客服电话

    020-85534346

    电子邮件

    81058337@qq.com
  • 码云社APP

    随时掌握码云社动态

  • 扫描二维码

    关注砺锋微信公众号

微服务架构实践 - 你只懂docker与spring boot就够了吗?

发布时期:2019-5-24 17:48
阅读:993 回复:20

微服务并不是单独存在的,为了更好地实现微服务架构,需要整合许多组件混搭使用,方能打通任督二脉,天下无敌。网上很多大拿讲了微服务治理的内容,也有人单方面讲微服务的,比如springboot与docker,本文着重于组件 ...

微服务并不是单独存在的,为了更好地实现微服务架构,需要整合许多组件混搭使用,方能打通任督二脉,天下无敌。网上很多大拿讲了微服务治理的内容,也有人单方面讲微服务的,比如spring boot与docker,本文着重于组件选型的较量,也积累了我们团队多次PK的精华;这些组件包括spring boot、spring cloud、docker、服务注册发现、RESTFUL、postman、jenkins、ELK、ETCD等。

背景

随着公司一年多的成长,我们已经开发了数十个项目了,后台有JAVA的有PHP的,为了更好地提升开发与管理效率,各技术大牛小牛们时常进行激烈的PK,碰撞出了许许多多爱的火花,比如其中之一:微服务实践

设计


微服务架构实践 - 你只懂docker与spring boot就够了吗?


微服务开发架构.png

只需要有一套BASE微服务,BASE微服务生成业务系统微服务实例,供各个业务系统调用;业务系统不直接调用BASE,只能调用微服务INSTANCE。

问题一:有些人会问,假如有20个业务系统,那就有上百个微服务,这怎么管理得了?

这是运维的问题,让运维去解决,运维使用工具,实际也不算困难,反正执行的都是脚本,不需要手工操作。

问题二:为什么不做成一个saas的微服务,这样就只有不到10个的微服务,就非常容易管理了不是吗?

单点故障影响全局,我们选择了稳定更重要;另外saas的话,为了应对不同行业,会存在过度设计的嫌疑;私有化更容易。

调用逻辑


微服务架构实践 - 你只懂docker与spring boot就够了吗?


调用逻辑.png

  • 客户端调用业务系统,不直接调用微服务;
  • 微服务内部也存在调用关系。


设计理念

1. 模块化是基础

非模块化,谈不上微服务,比如我们上面的用户微服务、产品微服务、地址微服务等,都需要先模块化,为了更好地落实开发,你可能不得不,边模块化边微服务,模块化的时候要注意,不能有关联查询,包要完全独立,到时候微服务才能拆开。


微服务架构实践 - 你只懂docker与spring boot就够了吗?


边模块化边微服务.png

  • 松耦合、强内聚

松耦合表示我们模块之间不直接依赖,无状态,可以单独地为外界提供服务;

强内聚是指,我们虽然要拆分成一个个小的微服务,但是也要考虑某些功能的强关联性,比如一个凳子是由四个脚与一个板组成,我们不能把四个脚与板分开售卖,就没有意义了。

开发

  • 强大而友好的spring体系

java开发5年以上的都非常清楚,很多JAVA框架都淡出了视野,比如hibernate、struts1、struts2,唯有spring越来越受欢迎。

spring-boot:较springmvc更加简约了,springmvc有一大零的配置文件,比如spring-servlet、spring-mybatis、spring.xml与web.xml,这些在spring-boot都不需要了,只需要强大的注解功能即可,boot更合适微服务。

spring-cloud:里面有比较多组件,用于支持微服务,比如spring cloud config统一配置中心,用于多环境的配置文件配置,大家再也不用为多个微服务的开发、测试与生产环境的配置文件管理而发愁了;spring cloud eureka用于服务注册与发现,下面有单独介绍;其它的组件大家可以去官网看看,这里不一一介绍,总之如果JAVA平台,尽量使用spring体系的内容。

  • 数据库

我们采用mysql,因为我们是应用多,但数据量单表并不算大,多则不超过百万,mongodb也实验过,开发非常快,也非常灵活,但因为不是关系型数据库,维护成本较高。

  • 权限认证

针对外部校验,内部完全信任机制。

微服务架构实践 - 你只懂docker与spring boot就够了吗?


权限认证.png

  • 接口规范

RESTFUL:URL的资源与操作解耦,让URL更加符合语义,上百个接口也非常好管理,网上有很多文章讲得非常透彻,这玩意不是特别好理解,要多领悟,在项目中实践,就有矛塞盾开的感觉,这里不做详细介绍。

接口文档swagger:比起传统全手工写接口文档,swagger有统一的输出格式,不管是几个人写的;swagger采用写代码的方式来写接口文档,以前修改了代码,还必须打开wiki手工修改接口文档,现在只需要修改一下代码即可,程序员更愿意修改了,成本更低了,前端与其它调用者不会天天吼着,你这接口咋又变了,新加的字段是啥意思呀。

  • 服务注册与发现:eureka

服务接口改变后,再也不需要口头通知服务调用者了,因为调用者太多,你根本不知道他是谁,难免遗漏;可支持PHP。

微服务架构实践 - 你只懂docker与spring boot就够了吗?


服务注册发现.png

  • 消息队列

RocketMQ:一直纠结kafka与rocketMQ,最终选择了RocketMQ

  • 异步编程方式

为了性能上面的考虑,尽量使用异步编程,比如注册送优惠券,那么注册成功就可以给用户返回注册成功了,但是送优惠券可以是异步调用的,不阻塞注册的线程。

  • 实时日志分析平台 ELK

微服务框架下,日志不可能还分散在各个服务节点上,必须有统一的日志中心。ELK是一个实时日志分析平台,就是将各个服务的日志汇总于日志中心,然后可以按照系统、节点等进行搜索,除上述搜索条件外,我们还在各个微服务实现了按照业务id(一次请求生成一个业务id)与用户id搜索日志,方便跟踪与定位问题。

  • 统一配置中心 ETCD

当然可能有更加轻量级与好用的disconf或spring cloud config,但是我们有php开发的应用,以上二者都不支持。如果全是JAVA应用,采用disconf还是非常不错的。

测试

微服务接口测试工具postman

每个程序员都有这样的经历,刚上线,客户又反馈了bug,原来是我们修改某个功能代码的时候,导致了其它功能的bug,每次上线心里都没底;这就体现了接口测试的必须性,尤其是每次版本升级的时候,都需要执行一遍,以防修改某个接口导致其它接口报错,比手动测试靠谱许多。

部署

微服务的好基友:docker

docker已经家喻户晓了,这是继虚拟机以后,又一重大变革,将所有的单个微服务都放在docker中,这样你何时何地想部署,直接丢过去就OK了,快到爆。

负载均衡利器:docker swarm

用几句简单的命令就搞定了负载均衡,而且还可以平滑升级,版本升级的时候,大家就不用告诉客户:系统通知,某日某晚00:00-08:00我行处于系统升级维护中,大家不要去取钱哦,因为你可能取不出来,呵呵。

升级

  • 数据库升级
  • 升级前对数据库做物理或逻辑备份
  • 数据库脚本不能含有删除或修改表与数据的语句,防止升级过程中旧业务报错
  • 所有脚本上线前运维人员必须check,一些敏感词drop或delete

我们采用工具flyway,可以对数据库脚本进行版本控制。

  • 持续集成

传统的版本升级,

1.开发推代码并同时记录自己提交了哪些文件;

2.项目经理根据svn审核文件,并打包成war包;

3.投到测试环境让测试公司测试;

4.中途修改了文件,可能需要重新打包;

….

我都写不下去了,项目经理像个超人似的。

现在用持续集成(CI)非常简单,我们用的工具是Jenkins,推完代码,点几下按钮就完成了上线,不管是测试环境,还是生产环境都非常简单,不然项目经理核对文件眼睛都绿了。

结尾

  • 最后说明

本文主要是介绍微服务开发上的选型,对于细则不做深究,大家感兴趣可以了解下各个组件。当然,我们的选型未免正确,不同场景应用可能完全不同,本文仅供参考。

请叫我吴少gg(未知职业)-本文作者
这个人很懒,什么也没有留下。
993 20 2019-5-24 17:48
该文章已有20人参与评论

请发表评论

全部评论

查看全部评论>>

扫一扫关注官方微信号

最前沿的技术信息一手掌握

滚动新闻
CODESEEDING(码云社)一家致力于程序员成长、以内容为核心、以提问为引导的多元化成长社区。我们在线上为技术爱好者提供了一个优质的交流氛围环境,在线下同样和众多高校联合开办了技术沙龙品牌。
020-85534346
关注我们
  • 访问移动H5版
  • 官方微信公众号

码云社 - CODESEEDING 2.0© 2018-2019 码云社. TOOBUG ( 粤ICP备16114193号-3 )