内部架构的范围确定和设计

值得注意的是，内部架构需要设计得比较简单，因此它才可以很容易地独立部署，或者单独废弃。一旦出现微服务失败或有更好的服务出现，可废弃性是必需的。无论是这两种情况下的哪一种，都需要可以很容易地废弃相应的微服务。微服务也需要获得部署架构和运行环境的强有力支持，微服务要在这样的运行环境中被构建、部署和执行。因此，它需要足够简单，这样才能独立部署。理想的做法是发布一个相同服务的新版本，加入对缺陷的修复，包括新的功能或者对现有功能的改进，并去除掉废弃的功能。

微服务架构建立的基础框架决定着对一个微服务架构的内部架构的关键需求。吞吐量、延迟和低资源使用率（内存和CPU）等都是需要考虑的关键需求。一个好的微服务框架通常会建立在轻量级、运行速度快和现代编程模型的基础之上，比如注释元配置，它与核心业务逻辑相独立。此外，它应该有能力来保障微服务的安全，满足必要的行业领先的安全标准，也应同时提供一些指标来监测微服务的行为。

与外部架构相比，内部架构中每一个微服务的实现都比较简单。在搜寻和设计内部架构时，一个好的服务设计要考虑到以下六个因素：

首先，微服务应该有单一的目的和单一的责任，并且服务本身应该作为一个独立的部署单元，可以在生产部署时创建多个实例。

其次，微服务应该有这样的能力，那就是可以采用一个最适合它要发布的功能的架构，并且此架构能够使用适当的技术。

第三，一旦单体服务被细分为微服务，每一项微服务或每套微服务就应该有可以通过API提供服务的能力。然而，在内部实现中，该服务可以采用任何合适的技术，实现业务需求，实现各自的业务能力。为此，企业可能要考虑像Swagger那样的东西来定义API规范或特定微服务的API定义，并且微服务能利用这个作为互动的点。这在微服务开发中被称为以API为先的方法。

第四，要部署的内容也可能有不同，比如捆绑在基于Hypervisor的镜像的独立的可部署单元，或者是容器镜像，这通常是更受欢迎的选择。

第五，企业需要利用分析来细化微服务，同时一旦服务失败要提供恢复手段。为此，企业要整合使用度量指标和监控来支持微服务的演进方法。

第六，即使微服务范式本身可以让企业的微服务有多种实现或多语言实现，对最佳实践和标准的使用对于保持一致性是非常必要的，同时要确保解决方案遵循一般的企业架构原则。这并不是说，多语言的机会就被完全否决了，而是说它们在使用时需要被监管。