关于微服务

微服务已经是一个时尚,使用2年,不写点什么介绍下,感觉缺憾。

微服务是什么?

微服务是:以若干 组可独立部署的服务的标签20方式进行软件应用系统的设计,没错,是一种架构设计方法。

微服务的特点

从上述的定义上可以看出,微服务包含如下的特点:

  • 一个应用包含多个服务
  • 每个服务都是独立部署的
  • 是软件架构设计的一种

微服务的优势和劣势

1、设计

根据复杂的问题简单化原则,无论是什么系统都有统一的指导方针,那就是把一个大系统划分为若干小系统的设计思路,微服务拥有天然的则个特征,我们必需思考有哪些微服务,每个微服务的职责。

然而如何划分好微服务却不是一件容易的事情,包括如下的几个问题:①微服务多大粒度合适;②微服务间的边界如何;③微服务间如何交互。微服务虽然指导我们简化我们的系统,然而,如果设计不好却容易引起更多的混乱。

2、开发

简单的东西更容易维护,作为一个单体的微服务有这个特征;

另外,在一个超大项目中,开发团队在地域上分布很广,根据微服务划分的不关于微服务同的开发小组可以减小大团队引起的沟通成本。

然而,无论是你调用其他微服务的接口或者别人调用你的微服务的接口,都不是一件轻松的事情,都意味着两方有时甚至多方的联调标签17。

有些时候,如果你对接口的修改,可能导致灾难性的问题,因为别人依赖你的接口了,你被迫开发一个接口的不同版本满足不同的人的需要。

最后,你需要对你的微服务涉外接口文档进行维护,方便其他同学调用你的接口。

3、测试

相对于单体应用,测试工作量是明显加大了。

任何一个功能,不仅要测试全链路的业务是否正常,还要测试全链路下单个微服务的状态死标签17否正确。

4、部署

简化部署,微服务因为简单,所以单个微服务是很容部署的,配合maven、jekins、Docker等构建工具,一键部署,单机应用都是简单的。

微服务下,一次版本可能要部署N多主机,这通过人工操作还是够喝一壶的,虽然单个简单,但是借助K8s等工具,也可以做到一键部署。

在部署上,如果有配套的工具,微服务还是简单的,如果没有配套服务,麻烦不少。

5、问题定位

一个订单失败了,你知道失败的原因吗?真不一定知道啥地方出错了,因为订单链路涉及了好多台微服务主机,有时甚至标签3日志都不知道哪去找。

一般的需要开发额外的全链路跟踪日志。

6、按需扩展

这关于微服务是微服务的主要优势,微服务可以按需扩展,对于交易量大的微服务从X轴扩展。

7、异构性

微服务间的交互是通过标准的数据交换协议,这些协议都支持不同的技术栈来实现,因此如果想融合或者尝试部分业务使用其他技术栈开发,完全是没有问题的。

这个优势增加了公司内部的想象空间,特别是大公司人关于微服务才齐备,合力搞定一个项目。

8、容错标签17性

微服务的运行在一个独立的进程上的,一个关于微服务单独的进程挂机后,不会影响整个系统其他功能,另外微服务通过其他的技术手段,如熔断、异常节点分离等技术手段,实现业务降级或者重新路由到正确的节点。

这是传统单体项目所不能想象的,传统单体项目运行在一个进程上,如果进程出现问题(如内存溢出),面临的必将是全盘崩溃。

微服务下的关键技术

1、一致性

微服务典型的分布式计算特征,设计过程标签10中即要求每个微服务拥有自己的数据库,传统的事务无法在分布式环境中复用,ACID无法在微服务中继续。

目前微服务的一致性技术主要通过三种方式:①可靠事件源;②业务补偿;③TCC,它们实现了微服务下的数据最终一致性。目前这些技术都有稳定的技术方案。

①可靠事件源,保证如下要点:

  • 发送可靠,确保业务发生事件提交时,事件成功发送
  • 确保监听事件服务收到事件通知
  • 确保事件重复发送时,监听事件服务的幂等处理

②业务补偿

大事务中的若干小事务失败时,对失败的小事务给出替代方案,或者要求已经成功的小事务全部取消,如一次旅标签11行,1)的士从家到飞机场;2)买票从广州到武汉;3)买票黄鹤楼;4)高铁回广州;如果1)失败了其他成功了,可以考虑使用机场快线代替的士,让全事务继续,当然也可以取消本次旅行。

③TCC(Try、Confirm、Cancel)

跟业务补偿有一点相似,只是关于微服务所有的这些小事务都是在锁定资源过程中,待最后全部锁定资源后,再一次性全部提交或者回滚,再以上述旅行为例,在TCC场景下,这些买票的过程都下了订单,但是没付钱,最后就是全部付钱或者订单全部取消,对应关系:

  • Try:下单,但是不关于微服务付钱
  • Confirm:付钱,旅行成功
  • Cancel:取消订单,旅行取消

TCC中也可能存在,部分提交成功,部分提交失败的场景,此时与②业务补偿处理一致,不过一般只做失败补偿,就是取消旅行。

2、健壮的微服务间服务调用

当微服务A调用微服务B时,会出现如下的问题

  • 被调用的标签19B节点挂掉了
  • 被调用的B节点很忙
  • 被调用的B节点返回时间很长
  • 被调用的B节点死掉很长时间了,现在是否可用了

这些问题都是微服务间调用关于微服务过程可能出现,如果不能处理,微服务将存在重大的安全隐患,最终整个系统可能因为少数的系统的问题而挂掉。

SpringCloud中,使用Hystrix解决这一些列的问题。

3、便捷的服务构建、发布和部署

基于微服务构建的系统,多则数十个微服务,每个微服务部署几个点,数量极其可观,使用传统的单体业务构建方法,标签3碰上一次版本上线,会有超大的工作量,并因此而导致系统故障。

基于SpringBoot+Maven+Docker+Jekins+K8s的微服务构建和管理套件,已经非常成熟,大大的缩短了版本发布时间,减小了故障。

4、迅速的日志标签3定位方法

在单体应用中,所有的业务日志都在一个文件中,根据异常现象,标签19可以很方便的找到问题日志(除非没有日志),在微服务场景下,微服务分布在众多的节点中,不同的节点有自己的日志,要搜索这些日志并标签17把这些日志串起来是一件不容易的事情。

SpringCloud中,包含zipkin等技术支撑全链路交易日志,但是仍需要开发过程二次开发和集成。

5、面向业务的服务编排(API网关)

微服务提供的接口多数是原子接口,服务编排则是把众多服务聚合后完成一个完整的业务功能的过程。

SpringCloud中通过Zuul实现的API网关,完成服务编排,最终向外提供完整的业务。

6、配置中心

哪些场景下适合或者不适合使用微服务

从上述的优劣势比较上,微服务并非银弹,相反,使用微服务存在巨大的代价,哪些场景下适用于微服务呢?

1、产品/项目

微服务不适合用于构建项目,国家特色,项目是需要快速交付的,使用微服务不能带来便利,反而会陷入数不完的坑中。

当然另一种场景除外,贵公司已经有大量的基础微服务,本标签1次的项目可以在标签17这些微服务的基础上构建,并且较少的改动。

2、团队要达到一定的规模

微服务从物理上割裂了整个系统,因此一般负责一个微服务时,经常对不相干的微服务不会关注。因此包括研发团队、运维团队等,如果太小了,每个人可能要负责多个微服务,然后发生人员变动时,部分微服务可能无人维护,或者突然觉得自己的工作量大了很多,因为多负责了一个模块,虽然可能那个微服务并没有多大工作量。

具体来说,标签19每个微服务最少要配备2人,一主一备,做到每个微服务都有专人支撑。

3、设计的门槛

相对于单体应用,微服务的设计有更高的门槛,体现在微服务的划分和微服务间的接口,否则微服务会带来更多的混乱。

发表评论

电子邮件地址不会被公开。 必填项已用*标注