我们都是架构师!
关注架构师(JiaGouX),添加“星标”
获取每天技术干货,一起成为牛逼架构师
技术群请加若飞:1321113940 进架构师群
投稿、合作、版权等邮箱:admin@137x.com
如果单体应用是一个人啥都干,那微服务体系更像是一个团队。相对于一个人大包大揽,一个团队中每个人分工合作显然对于整体来说是更轻松的,弹性也更强,但是团队相对于个人研发无疑增加了沟通成本,也就是信息共享(数据共享)
数据共享的问题,就如同大家都会讲普通话,那大家就都用普通话沟通,但是不能前端页面问题找DBA处理,这时候我们就需要统一各个成员之间的依赖关系,比如A前端关于样式方面的问题需要找B设计师,C后端关于数据库方面的问题需要找DBA,这也就是微服务间数据依赖关系的问题,服务与服务之前相互依赖构成一套微服务系统,服务独立管理自己的职责,从而达到<协同工作,小而自治>
在精简的团队里,通常我支持每个成员单独负责一个微服务模块的开发,从而在团队和架构层面都达到分而自治,然后在代码走查阶段互相阅读‘找茬’,提高整体代码质量同时团队中成员能够互相学习。
对于服务间的依赖通常是单向依赖,比如A服务依赖B服务的数据,但B服务不应该依赖A服务的数据,这样能够避免服务间关系混乱的问题,有利于问题排查和性能优化。
现有三个微服务A、B、C,其中A依赖了B,B依赖了C,如果B提供API聚合了C提供的数据,这时候此API不建议直接提供给A使用,而应该A单独调用B和C进行数据聚合。这样的好处在于避免了层层调用,A服务可以对B、C服务并行调用,性能也会更优。
对面上面A服务同时调用BC服务数据的情况,如果使用场景较多,这时候可以提供一个接口聚合服务,相当于一个中间商,中间商将BC提供的数据组合后为A提供服务。
就像浏览器与服务器一样,微服务两两之间也服务与客户关系,而且两两之间应该一直是这种关系
微服务一方面为客户端提供API服务,也为其它微服务提供API服务,所以在API设计要考虑到2C API与提供给微服务的API之间参数与返回值上的区别,通常返回给客户端的API我们进行了包装,包含了数据、状态、错误信息等等,但是对于微服务之间的API,直接一点更好,是列表就返回列表,是对象就是对象,调用方只需考虑异常即可,而不用去考虑太 多了参数校验等等问题。
对于服务与服务之间,是一种信任的关系,调用方更多考虑被服务方是否会出问题,而服务方更多是信任调用方是可靠的(约定大约限制),简化调用方传参及返回值结构;对于服务与客户端之间的关系,更多是一种不信任的关系,我们要考虑客户中有坏人,对参数进行严格校验、对异常操作给出警告(错误信息)。
对于微服务系统,通常有一个基础系统(base-data),其它微服务依赖于此系统管理的基础数据,如用户的基础信息,在微服务搭建的初期要将此类基础数据划分出来进行基础管理。基础系统管理大缓存,进行数据同步,其它微服务都依赖此缓存进行业务聚合。
微服务相对于一体服务,数据共享与通信是关乎微服务性能及可靠性的问题,我们在服务设计阶段要尽量简化关系,高度抽取,服务能少则少的原则。
以上内容纯属个人在微服务开发体系下的一些理解与总结,如有误区请指出,如果有补充欢迎在评论区交流。
如喜欢本文,请点击右上角,把文章分享到朋友圈
如有想了解学习的技术点,请留言给若飞安排分享
·END·
相关阅读:
作者:热黄油啤酒
来源:https://juejin.cn/post/7070418676754677768
版权申明:内容来源网络,仅供分享学习,版权归原创者所有。除非无法确认,我们都会标明作者及出处,如有侵权烦请告知,我们会立即删除并表示歉意。谢谢!
我们都是架构师!
关注架构师(JiaGouX),添加“星标”
获取每天技术干货,一起成为牛逼架构师
技术群请加若飞:1321113940 进架构师群
投稿、合作、版权等邮箱:admin@137x.com