微服务架构中最理想的模型是每个服务可以单独执行并且具有自己的业务逻辑、数据库、中间件、机器资源，并且随着业务逻辑的改变，相应功能的开发和配置成本低。一个电子商务系统分为用户管理、订单管理、库存管理、支付管理等微服务模块。业务扩展后，需要追加另一个优惠券管理模块，更加方便地追加。直接开发这个模块的功能，向微服务网关添加路径。

然而，问题是如何管理来自微服务的分裂的多个微服务。作为优化容器，可能需要最低水平的硬件资源。之后进行完全自动化系统的开发、测试、发布和维护。这些基本能力的建设和维护成本也很高。因此，在技术改革中，需要考虑到自己的业务进行快速反复吗？基础力的建设怎么样？不要把马车放在马的前面。

微量服务困难状况的分布状况

该消息必须使用微服务技术架构并使用分布式配置架构。分布式架构可以将单机开展的业务分成多台展开，根据业务状况，具有无限的灵活性，实现高性能、高利用性、高合并性。

但是，使用分散装置的情况下，也存在数据的整合性等很多问题。提供这个服务的服务，因为不同用户的数据版本不能不同，所以整体上都很混乱。因此，在使用分布式服务模式之后，分布式事务保证了工作的原子性，在多人以相同服务工作时需要分布式锁的原子性。这些是使用分布式架构的额外费用。我们必须享受并支付这些费用。技术改革需要考虑自己的业务是否需要高功能？可以负担分布式的费用吗？不要因为一点小事就出大事故。

为微型服务困难04服务通信

在服务不拆分微服务之前，模块与模块之间的通信通过内部呼叫来实现，并且不存在网络延迟。但是，如果服务分类为微服务，模块就会变成微服务。微服务与微服务之间的网络通信是外部呼叫的实现。如果网络通信有问题的话，整体的服务质量就会降低。因此，在技术改革中也需要考虑非技术成本等。

微服务确实不错。例如，阿里、京东、美团、滴滴等大型互联网公司将自己的业务系统升级为微服务体系。公司整体的在线是微服务系统。另外，我们可以参考大工厂的经验，但在实际开始之前，必须结合自己的经营状况和资源状况来测定它们是否真正适合。