回顾微服务架构场景

为了全面正确地看待事情，我们分析一些实际场景，这些场景展示了微服务架构的内部和外部架构如何一起运作。我们将假设组织已经使用微软Windows Communication Foundation或Java JEE/J2EE服务框架实现了她的服务，并且开发人员还在写新服务代码，使用的是应用了微服务架构原则的微服务框架。

在这种情况下，提供数据和业务能力的现有服务不能被忽视。因此，新的微服务将需要与现有服务平台之间相互通信。在大多数情况下，这些现有的服务将使用框架所坚持的固有标准。例如，旧的服务可能使用服务绑定，比如HTTP上的SOAP、Java Message Service（JMS）或IBM MQ等，并使用Kerberos或WS-Security进行保护。在这个例子中，消息渠道也将在协议转换、信息转换、从旧架构通向新的微服务架构的安全过渡中起重要的作用。

另一个组织需要考虑的方面是在业务增长方面可能造成的对其可扩展性的影响，由于单体应用在这方面是有很明显的局限性的，而微服务架构是可以横向扩展的。在这些明显的限制中，还有可能的错误，因为在一个单片环境里测试新的功能非常繁琐，会导致延迟实现这些变更，成为满足快速提交需求的障碍。另一个挑战将是在所有者缺失的情况下支撑这个单体的代码库，在微服务的情况下，个人或单个功能是可以自己管理的，这些可以在不影响其他功能的情况下根据需要迅速扩展。

总之，虽然微服务对于组织有显著的好处，以逐步淘汰或迭代的方式向前推进微服务架构以确保平稳过渡，这可能是最好的办法。能使微服务架构成为被优先选择的以服务为向导的方案，其关键是明确所有权，以及它可以将故障隔离，从而使这些所有者可以把他们的领域内的服务实现得更加稳定和高效。