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