背景
web
服务也经历了很多的演变;在公司业务稍微简单的时候,采用简单的服务,可以提高开发效率,可以帮忙节省更多的成本。但随着用户数量的剧增,流量突增;业务越来越复杂,简单的服务也来不满足公司的发展。接下来就简单列一下服务架构。单体服务
jar
。当然为了服务有更好的性能,我们的服务不会只布在一台服务器上,如下图所示。nginx
的反向代理,通过负载均衡算法,可以将终端的请求转发到其中的一个web
服务中。因此这样的架构也有优点:-
高可用,我们可以部署多个服务器; -
简单,所有的功能都可以在一个服务器上处理,只需配置一下转发即可; -
性能也较好,所有服务器上都可以处理所有的业务逻辑,并且没有后端之间的远程调用。
jenkins
这种方式进行打包,使用脚本启动服务。但是当随着业务逻辑越来越多,越来越耦合,如果这是时候出现了代码bug
,就会导致整个服务不可用,或者任务阻塞,导致服务器没有资源去做其他的事情。并且随着代码越来越多,代码的维护也越来越复杂,改了某个地方会导致其他业务不能用。因此,在这样一个背景下,怎样去搭建一个低耦合,高内聚的服务呢?单节点微服务
rpc
进行访问。如下图所示:rpc
之间进行调用。通过这样划分,可以实现以下的优点:-
灵活性得到更大的提高,比如相应的设备逻辑,我改相应的服务,而不会影响定时,设备控制等服务。 -
业务的独立性得到增强,开发的难点得到了降低。
rpc
,所以性能有所下降;各个服务之间交互,各自会维护自己的数据库,在相互通信的过程中,数据的一致性难以保证。混合服务
结语
CAP
原则,BASE
理论。在这些理论中,主要强调,可用、性能、一致性的取舍。为了满足用户的良好体验,我们在设备的过程中,需要跟多地满足可用和性能两个要素,其中的数据一致性,我们更多地采用一种软一致性,通过一种时间换空间的方式来保证数据的一致性。原文始发于微信公众号(CodeJames):物联网-常见的服务架构演变
© 版权声明
文章版权归作者所有,未经允许请勿转载。
THE END
喜欢就支持一下吧
相关推荐
暂无评论内容