微服务的想法并不新鲜。 老年人可能在鼎盛时期使用过
EJB 。 这是什么，
塞缪尔·柯尔特（Samuel Colt）已经使用模块化方法来制造他的左轮手枪。 他手枪的标准，精密制造的零件是可以互换的，从而大大简化了生产和维护。 那么，为什么不应该将基础架构模块化？
对此没有根本的异议，而且这个想法本身是表面上的。 但是微服务的话题最近才变得很流行。 这是有原因的。
长期以来，基础架构的维护仍然是一项艰巨而专业的工作。 只有熟练的管理员才能在基础架构中部署任何缓存或队列。 应用程序的每个部分都有其自己的基础结构，毫无疑问-谁将为整个动物园服务？
但是虚拟化技术，容器和基础架构配置管理工具已经走了很长一段路。 现在，与将所有服务推送到通用基础架构中相比，为单独的应用程序服务部署独立基础架构变得更加容易和便宜。 进步！
出于组织原因，该应用程序方便地分为多个独立部分。 在这种情况下，各部分之间的交互是通过一个或另一个API进行的。 最重要的是服务。 从这里开始，将应用程序划分为Amazon中的宏服务，都市服务，微服务，纳米服务，微微服务和单行lambda函数的过程。
看来这里可能出什么问题了？
las，将应用程序分成多个部分并不是免费的。 首先，在基础架构内部支持API的成本正在增加。
假设应用程序需要使用文件。 一个典型的任务。 分配了一个用于实现文件存储基础结构的微服务；它提供两种操作：读取和写入。 而且，在不对API进行重大更改的情况下，此类服务可以从接口扩展到本地磁盘上的文件夹，再到地理分布的数据中心基础结构。 完美的场景。
但是，如果将应用程序划分为服务，使业务逻辑的奇数行最终出现在一个服务中，而偶数行最终出现在另一个服务中，该怎么办呢？ 这样的分离不仅会大大降低应用程序的速度，因为现在将发生网络通信，而不是直接调用该方法，因此服务之间的API更改的频率非常高，以至于适合API版本号的长版本。
当然，这全部是夸张的。 但是，它清楚地显示了可能的负面后果。 以这种方式构建的应用程序开发成本非常高。
在将应用程序分为几部分之前，应考虑两个方面。
第一个 这些组件在一次操作中将多久互动一次？ 是否有可能对于每个操作都必须执行数百个（即使不是数千个）网络调用。 这会破坏应用程序的性能。
第二个。 API在组件之间多久更改一次？ 如果git的故事表明API每天都会变化，那么维护它的成本可能会过高。 这会破坏开发生产力。
但是，通过将应用程序正确划分为服务，您可以获得显着的收益。 只是这些服务不必是微型的。