单服务架构与微服务架构优缺点

你们好，今天咱们来比较一下单服务架构和微服务架构。

若是你在作网络应用开发程序的话，你必定考虑过到底用单服务架构仍是微服务架构。总的来讲，无论你采用哪一种架构，你均可以写出很是完美的网络应用程序来。

那么这两种架构到底哪个更好一些呢？回答这个问题以前，首先要看你网络应用程序的功能需求。

【单服务架构开发速度快】

单服务架构是一直以来的传统服务器架构， 它在一台服务器上运行，而后由单一的程序提供服务。

这种服务架构的好处，开发速度快，运行效率高。开始的时候你能够写出最基础的运行工做流程来，而后在之后的扩展中不断的添加功能。

【单服务架构运行速度快】

单服务架构为何比微服务架构快？那是由于单服务架构没有多余的服务之间的通讯。像微服务架构，里面有不少微服务，它们之间的通讯都是经过HTTP来进行的，若是你用微服务系统的话，这是不可避免的。单服务架构则不须要这一部分额外的性能消耗。

简单的讲，就是单服务架构的程序是运行在一个程序空间里面的，程序里面的数据共享是在程序空间以内进行的。那固然速度就很快了。

具体来说，就是单服务架构会有一个统一的数据库，每一个功能模块，好比说用户验证，订单管理，产品管理等等，都会访问一个数据库。

由于是共用一个数据库，那么它们就会装在一台服务器上共享一套操做系统和文件系统。

【微服务架构系统的特色】

下面来看一下微服务架构系统。

微服务架构系统中，每个服务都是一个单独的程序空间，好比说用户管理是一个单独的程序空间，订单管理也是一个单独的程序空间，产品管理也是一个单独的程序空间。这些程序空间能够有本身的独有数据库，甚至每一个程序空间均可以跑在单独的服务器上。

那么这些服务是怎么工做的呢？好比说，用户在进入网站以前，首先要调用用户管理服务，检查是否登陆成功了。若是登陆成功之后就能够拿着得到的token， 去订单管理那边拿数据，从而能够获取本身的订单，也能够进行下订单等操做。这些服务之间的交互都是经过HTTP的通讯方式来进行的。

通讯的方式的载体通常是用json数据做为统一格式。

【单服务架构系统在容错性的缺点】

那么咱们来看一下单服务架构会有什么问题呢？单服务架构的主要问题就是做为一台服务器上跑着的一个程序空间，你在修改某个部分的时候须要经过完整测试，从而保证全部的程序模块均可以安全的正常的运行。若是你的程序有某一部分写的不是很好的话，可能会影响到总体的运行。

特别是当你的服务框架很是庞大，你的程序规模很是庞大的话。一点小小的改动，可能要从新编译全部的程序，而且从新部署全部的程序，要知道单服务架构的整个程序空间是跑在一个进程里面的。

【微服务架构系统容错性的优势】

那么微服务架构，是怎么作的呢？单服务架构系统，由于把全部的部分都分红单独的程序空间，也就是单独的进程。这样能够把每个部分部署到单独的服务器上。

这样你在修改一部分的时候，只须要部署这一部分，只会影响到你当前的这个程序空间，不会影响到其余的部分。

测试方面来讲，微服务架构的每一个单独的服务是能够进行单独测试的。

在运行的过程当中，微服务架构中的某个服务，若是失败了的话，还能够有替代品。这样整个服务并不会失败。若是没有替代服务的话，直接返回，当前的页面不存在就能够了。

可是在单服务架构系统中，若是某一部分失败的话，会致使整个服务程序都没法运行了。由于单服务架构系统中只有一个进程，这个进程死掉了，固然全部的相关服务都不能运行了。

【微服务架构系统可扩展性和可重用性的优势】

用微服务的最大好处就是你能够无限的添加各类的服务， 能够无限的扩展你的程序。

还有一个好处就是微服务可重用性。能够把现有的服务模块进行从新组合，再添加几个新模块作成一个新的程序应用来。

也就是说微服务架构的程序，重用起来的话，更容易一些，几乎不须要改动现有的代码了。

【开发模式不一样】

开发模式上来讲，单服务架构系统由于是一个程序，因此只能选一种技术来开发，若是你有足够的人手，可以很快的完成任务，保证项目质量是没有问题的, 而且必定要解决好协同工做的问题。

微服务架构，由于每一个服务都是比较独立的，开发人员能够专门攻克某一个服务，能够用不一样的技术来开发。固然对一个服务来讲，只能用一种技术了。这种模式能够实现多个程序员同时并发的工做互不影响。每一个程序员只须要负责某个服务的质量就能够了。

因此综上所述，至于选哪种架构取决于以下几个因素：

你工程的规模怎么样？

工程的进度是否是很赶？

多长时间想把这个项目作出来？

工程的预算有多少钱？

开发者的水平怎么样？

后期的可扩展性是怎样的要求？