单服务架构与微服务架构优缺点
大家好,今天我们来比较一下单服务架构和微服务架构。
如果你在做网络应用开发程序的话,你一定考虑过到底用单服务架构还是微服务架构。总的来说,不管你采用哪种架构,你都可以写出非常完美的网络应用程序来。
那么这两种架构到底哪一个更好一些呢?回答这个问题之前,首先要看你网络应用程序的功能需求。
【单服务架构开发速度快】
单服务架构是一直以来的传统服务器架构, 它在一台服务器上运行,然后由单一的程序提供服务。
这种服务架构的好处,开发速度快,运行效率高。开始的时候你可以写出最基础的运行工作流程来,然后在以后的扩展中不断的添加功能。
【单服务架构运行速度快】
单服务架构为什么比微服务架构快?那是因为单服务架构没有多余的服务之间的通信。像微服务架构,里面有很多微服务,它们之间的通信都是通过HTTP来进行的,如果你用微服务系统的话,这是不可避免的。单服务架构则不需要这一部分额外的性能消耗。
简单的讲,就是单服务架构的程序是运行在一个程序空间里面的,程序里面的数据共享是在程序空间之内进行的。那当然速度就很快了。
具体来讲,就是单服务架构会有一个统一的数据库,每个功能模块,比如说用户验证,订单管理,产品管理等等,都会访问一个数据库。
因为是共用一个数据库,那么它们就会装在一台服务器上共享一套操作系统和文件系统。
【微服务架构系统的特点】
下面来看一下微服务架构系统。
微服务架构系统中,每一个服务都是一个单独的程序空间,比如说用户管理是一个单独的程序空间,订单管理也是一个单独的程序空间,产品管理也是一个单独的程序空间。这些程序空间可以有自己的独有数据库,甚至每个程序空间都可以跑在单独的服务器上。
那么这些服务是怎么工作的呢?比如说,用户在进入网站之前,首先要调用用户管理服务,检查是否登录成功了。如果登录成功以后就可以拿着获得的token, 去订单管理那边拿数据,从而可以获取自己的订单,也可以进行下订单等操作。这些服务之间的交互都是通过HTTP的通信方式来进行的。
通信的方式的载体一般是用json数据作为统一格式。
【单服务架构系统在容错性的缺点】
那么我们来看一下单服务架构会有什么问题呢?单服务架构的主要问题就是作为一台服务器上跑着的一个程序空间,你在修改某个部分的时候需要通过完整测试,从而保证所有的程序模块都可以安全的正常的运行。如果你的程序有某一部分写的不是很好的话,可能会影响到整体的运行。
特别是当你的服务框架非常庞大,你的程序规模非常庞大的话。一点小小的改动,可能要重新编译所有的程序,并且重新部署所有的程序,要知道单服务架构的整个程序空间是跑在一个进程里面的。
【微服务架构系统容错性的优点】
那么微服务架构,是怎么做的呢?单服务架构系统,因为把所有的部分都分成单独的程序空间,也就是单独的进程。这样可以把每一个部分部署到单独的服务器上。
这样你在修改一部分的时候,只需要部署这一部分,只会影响到你当前的这个程序空间,不会影响到其他的部分。
测试方面来说,微服务架构的每个单独的服务是可以进行单独测试的。
在运行的过程中,微服务架构中的某个服务,如果失败了的话,还可以有替代品。这样整个服务并不会失败。如果没有替代服务的话,直接返回,当前的页面不存在就可以了。
但是在单服务架构系统中,如果某一部分失败的话,会导致整个服务程序都无法运行了。因为单服务架构系统中只有一个进程,这个进程死掉了,当然所有的相关服务都不能运行了。
【微服务架构系统可扩展性和可重用性的优点】
用微服务的最大好处就是你可以无限的添加各种的服务, 可以无限的扩展你的程序。
还有一个好处就是微服务可重用性。可以把现有的服务模块进行重新组合,再添加几个新模块做成一个新的程序应用来。
也就是说微服务架构的程序,重用起来的话,更容易一些,几乎不需要改动现有的代码了。
【开发模式不同】
开发模式上来说,单服务架构系统因为是一个程序,所以只能选一种技术来开发,如果你有足够的人手,能够很快的完成任务,保证项目质量是没有问题的, 并且一定要解决好协同工作的问题。
微服务架构,因为每个服务都是比较独立的,开发人员可以专门攻克某一个服务,可以用不同的技术来开发。当然对一个服务来说,只能用一种技术了。这种模式可以实现多个程序员同时并发的工作互不影响。每个程序员只需要负责某个服务的质量就可以了。
所以综上所述,至于选哪一种架构取决于如下几个因素:
你工程的规模怎么样?
工程的进度是不是很赶?
多长时间想把这个项目做出来?
工程的预算有多少钱?
开发者的水平怎么样?
后期的可扩展性是怎样的要求?