标签：进程 用户 token 获取 服务 订单 测试 检查 预算
单服务架构和微服务架构比较
单服务架构，传统服务器架构， 在一台服务器上运行，由单一的程序提供服务。
优点：
开发速度快，运行效率高。开始的时候你可以写出最基础的运行工作流程来，然后在以后的扩展中不断的添加功能。
单服务架构的程序是运行在一个程序空间里面的，程序里面的数据共享是在程序空间之内进行的，所以速度快。
单服务架构有一个统一的数据库，每个功能模块，比如说用户验证，订单管理，产品管理等，访问同一个数据库。共用一个数据库，在一台服务器上共享一套操作系统和文件系统。
缺点：
作为一台服务器上跑着的一个程序空间，修改某个部分需要通过完整测试，保证所有的程序模块都安全的正常的运行。如果程序某一部分写不好，会影响整体运行。特别是当服务框架非大，程序规模大，小小的改动，可能要重新编译所有程序，并且重新部署所有程序。
只能选一种技术来开发，
微服务架构系统，每一个服务都是一个单独的程序空间，比如说用户管理是一个单独的程序空间，订单管理也是一个单独的程序空间，产品管理也是一个单独的程序空间。这些程序空间可以有自己的独有数据库，甚至每个程序空间都可以跑在单独的服务器上。那么这些服务是怎么工作的呢？比如说，用户在进入网站之前，首先要调用用户管理服务，检查是否登录成功了。如果登录成功以后就可以拿着获得的token， 去订单管理那边拿数据，从而可以获取自己的订单，也可以进行下订单等操作。这些服务之间的交互都是通过HTTP的通信方式来进行的，通信方式的载体一般json数据。
优点：
单独的程序空间，单独的进程。可以把每一个服务部署到单独的服务器上。修改一部分，只需要部署这一部分，只会影响当前程序空间，不会影响其他。
每个单独的服务可以进行单独测试
可扩展性和可重用性
选哪一种架构取决于如下几个因素：
工程的规模
工程的进度是不是很赶
工程的预算
开发者的水平
后期的可扩展性
标签：进程 用户 token 获取 服务 订单 测试 检查 预算
原文地址：https://www.cnblogs.com/hofmann/p/12966410.html
