在了解了微服务架构后，我们来分析下微服务架构又哪些缺点和难点。方式1：引入的外部开发商进行微服务架构化如果一个企业本身IT部门规模小，软件以外购为主，那么势必在对ERP等各类软件的选型评估后引入不同的软件产品提供商或软件开发商。
生活服务类app有什么推荐吗？
恋爱基金两个人每天存10块，一起见证数字从0到10000的变化过程，年底就可以一起旅行。一起努力、一起体验、一起实现，过程中的回忆也都记录了下来。重要的不是金钱和旅行，而是彼此从无到有朝同一共同目标努力的过程。就如同你们的爱情是在点滴积累中变得刻骨铭心。向日葵远程控制这是一款远程桌面控制app，当女友遇到软件不会用、资料放家忘拷贝时，通过这款软件你能在任何地方轻松帮她搞定。
APP服务端接口，用jwt还是用redis和token，分别有什么优势？
jwt属于无状态设计，用户登陆的信息关键存放在jwt加密数据里，这种设计下服务器不需要存储jwt密文，只需要解密就能拿到授权信息等用户信息。这种设计是一种利用计算力减少token设计下数据库及缓存的压力和设计复杂度，因此它的本质就是不存储登陆授权，而通过密文本身保存授权信息。token加redis设计，是一种登陆后分配随机token，然后记录token与用户信息对应关系的设计。
很明显，这两张设计的区别就在于token实际上是需要服务器存储，每次验权需要查询数据库。jwt不需要服务器存储，信息本身就存储于jwt本身，这种模式无需使用数据库。但是这种流行的jwt有一个设计上的缺陷，他通过密文传输用户信息，那么服务器在这种基础结构下是无法做到关闭用户登陆授权的操作，如果用户的jwt密文被偷窃，那么黑客就能以用户身份登陆，并且即使知道密文丢失，也无法关闭被偷窃的jwt密文。
为了应对这一问题，可以使用jwt内部验证有效期和jwt黑名单模式，但是有效期始终无法做到及时停止jwt授权，这是一个治标不治本的方法。而jwt黑名单模式，则需要数据库或内存存储黑名单，那么，这实际上违背了jwt的免数据库设计原则。因此，如果严格按照两种模式设计，jwt更适合低安全级别的服务器设计，如普通的博客、阅读器等等，这种服务允许不严格的登陆授权，即使密文丢失也不会造成用户的严重损失，却能获得较高的服务性能。
token模式，必须配合数据库进行存储和查询，因此性能较低，但token模式却能做到及时的授权关闭，已经登陆授权可见可查，每一次token都会有对应的记录。因此token模式适合较高安全度和用户登陆等信息分析的系统，如政府系统，支付系统等不可能允许高权限的token被偷窃却不能及时关闭授权。jwt，适合轻量的系统和权限不严格系统。
token，适合重量系统和权限有严格要求的系统。谢谢大家的阅读和头条的推荐，我再来详细的和大家讨论下这两者在实现上的区别，这样大家可能更方便的理解这两个不同的概念。我们讨论的这两种方式只限于规范实现，如果有其他优化或者衍生设计模式则不在讨论之内。token：普通的token方式采用的是：登录--
