课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
微服务架构是随着互联网的不断发展而逐渐被程序员掌握的一种架构方式,而今天我们就一起来了解一下,微服务架构实践都有哪些开发原则。
1、接口分离
初进行接口设计的时候想着复用,随着项目的推进,发现这个接口越来越臃肿,这里的臃肿不单单是代码量上的增加,更多的是一个接口出现了很多的调用方,后台、小程序、苹果端、安卓端、三方等,这就导致了同一个服务逻辑里面需要对接很多客户端,后期在进行代码修改的时候经常是牵一发而动全身,所有的客户端不可用的情况会越来越常见,这就是为什么我们要将接口进行隔离。
2、可部署性
从软件发展至今,从来没有一个时期像微服务这样子它的部署会成为重中之重,笔者认为,这一切都是互联网快速发展的产物,快,轻,持续才能满足现在高速变化的C端需求,特别是像我们人口基数这么大的国家来说。
在微服务的应用中,强调的是每一个服务可独立部署,独立拓展,在应用上是隔离的,这里要区分上面的接口隔离,接口隔离更加注重某一个应用对外的服务提供策略,这里更趋向于业务边界、性能边界、技术边界三者。在设计里面,设计模式及其他设计策略,主要还是集中于每一个独立应用,应尽可能避免过度依赖的同时一些通用的“组织”应该形成连锁依赖,从而避免过渡设计与过渡开发,又可以实现独立服务运行,这个考验每一个架构师的技术功底及业务功底。
3、事件驱动
提到微服务的事件驱动就不得不讲一下微服务的调用方式,通常我们采用以下三种调用方式
Rest风格的Http调用
RPC调用,做过dobbo的同学应该知道dubbo里面的RPC调用,开源的有gRPC可以使用
消息中间件方式进行调用
这三种方式没有绝对的好坏,需要根据实际场景来做决策,用得多的还是采用http的方式进行调用,RPC少。相对于消息中间件,其他两种方式都是同步阻塞式,当然现在很多应用都是这种方式,很多应用也需要这种方式,异步处理不好容易出现服务灾难。
4、松耦合
一直在强调高内聚低耦合,但是怎样的程度才算高内聚低耦合?都没有一个很标准化或者可量化的东西来说明,也许很多人说的就真的就是随口一说的概念。在微服务中,服务与服务之间往往存在调用关系,采用约定的方式来对服务之间进行解耦,实现服务交互,这种我们称之为服务契约。
服务契约的形成往往通过约定的技术手段来实现,约定好输入输出的规范,约定好输入输出的方式(HTTP或者MQ),约定好数据聚合方式,这种约定俗成的规矩可以帮我们减少服务与服务之间调用错乱的问题,成功的对每个服务进行解耦,同时每个服务在自身应用中可以做到高内聚,不过这里面笔者认为重要的一点就是服务的划分,下面会通过服务的职责问题来讲解。
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!更多内容请在707945861群中学习了解。