共计 836 个字符，预计需要花费 3 分钟才能阅读完成。
微服务零碎绝对于以往的单体零碎更为简单。在构建的时候，研发团队必须要治理和反对很多组件，环境会变得更加简单。上面是我以往构建微服务零碎时整顿的一些次要挑战。
一、限界上下文
限界上下文概念起源于畛域驱动设计 (DDD) 圈子。它的呈现促成了优先对象模型的服务办法，定义了服务责任和绑定的数据模型。有边界的上下文廓清、封装并定义了模型的特定责任。每个模型都必须在子域内隐式定义一个上下文，并且每个上下文都定义了边界。换句话说，服务领有其数据并对其完整性和可变性负责。它反对微服务最重要的个性：独立性和解耦。
二、动静扩大和缩减
不同微服务上的负载可能在不同类型的实例上。除了主动扩大你的微服务应该主动缩减。升高了微服务的老本，能够动态分配负载。
三、监控
传统的监控形式与微服务差异性很大，微服务有多个服务组成了单个应用程序反对的雷同性能。当应用程序中呈现谬误时，找到根本原因具备很大的挑战性。
四、容错
容错是不会升高整个零碎的单个服务。当故障产生时，应用程序能够在肯定的满意度下运行。如果没有容错能力，零碎中的单个故障可能会导致齐全解体。断路器能够实现容错，它是一种将申请包装到内部服务，并检测它们何时呈现故障的模式。微服务须要肯定水平上容忍外部和内部故障。
五、循环依赖
跨不同服务的依赖治理，这个性能十分重要。如果不及时辨认和解决，循环依赖可能会产生问题，当依赖关系造成了环，最终导致：在装置 A 软件包之前，必须要装置 A、B、C、D 软件包
六、DevOps 文化
微服务非常适合 DevOps。它提供更快的交付服务、跨数据的可见性和具备老本效益的数据。它能够将他们对容器化转换的应用从面向服务的架构 (SOA) 扩大到微服务架构 (MSA)。
微服务的其余挑战
随着咱们增加更多微服务，咱们必须确保它们能够一起扩大。更多的粒度意味着更多的组件，减少了零碎的复杂性。
传统的日志记录是有效的，因为微服务是无状态的、分布式的、独立的。日志记录必须可能跨多个平台关联事件。
当更多的服务互相交互时，失败的可能性也会减少。