课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
微服务架构是随着互联网的不断发展而逐渐被程序员掌握的一种软件架构方法,而今天我们就一起来了解一下,微服务架构与单体架构的区别。
1、复杂性
考虑复杂性时,有许多因素在起作用:开发的复杂性和运行软件的复杂性。
由于开发的复杂性,在构建基于微服务的软件时,代码库的大小会快速增长。因为微服务涉及多个源代码,使用不同的框架甚至不同的语言。由于微服务需要彼此独立,因此经常会有代码重复。
另外,由于开发和发布时间不一致,因此不同的服务可能会使用不同版本的库。
对于日志和监控方面,在单体应用中,日志记录就像查看单个日志文件一样简单。但是,对于微服务,跟踪问题可能涉及检查多个日志文件。不仅需要查找所有相关的日志输出,而且还需要以正确的顺序将它们放在一起。
在Kubernetes集群中运行微服务时,复杂度进一步增加。虽然Kubernetes启用了诸如弹性伸缩等功能,但它并不是一个易于管理的系统。要部署单体应用,简单的复制操作就足够了。要启动或停止单体应用,通常只需一个简单的命令即可。还有与单体应用相比,事务还增加了运行微服务架构的复杂性。跨服务的调用,很难保证数据是同步的。例如,执行不当的调用,重试可能会执行两次付款。
2、资源使用
一般来说,微服务会比单体应用使用更多的资源。即使在Docker中运行时,基准测试发现,虽然服务连接数量下降了8%,但是容器编排还将消耗资源,日志聚合和监视也将消耗资源。
但是,微服务使我们可以更聪明地使用资源。由于集群管理器可以根据需要分配资源,因此实际的资源使用量可能要低得多。
在软件中,20%的代码一般会完成80%的工作。如果单体应用的一个实例使用8GB,则两个实例使用16GB,依此类推。使用微服务后,我们可以把单体应用中负责主要职能的20%代码提取成一个服务,因此对于两个实例,我们的RAM使用量为降低到了9.6GB左右。
3、扩展的精确性
单体应用的扩展有多种办法,运行多个实例,或运行多个线程,或者使用非阻塞IO。对于微服务架构,这三个也都是适用的。
但是,面对客户端越来越多的请求,由于微服务架构更精细,因此扩展单个服务也更加精细。所以,对于微服务来说,扩展既简单又精确。而且,由于微服务的资源消耗较少,又可以节省资源。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请在707945861群中学习了解。