通过微服务基础知识、领域驱动设计概念和编码最佳实践成功使用微服务的组织可以充分利用Kubernetes/容器原生的优势。行业专家参加了DevOpsInstitute最近关于企业Kubernetes的SkiLUp演讲。在题为“通过持续交付在Kubernetes之旅中导航”的会议中，业界讨论了企业Kubernetes的状态以及持续交付对那些使用容器技术的组织的影响。他演讲的中心主题是Kubernetes如何为交付团队引入新范例。对于使用微服务的组织而言，其成功采用可能多种多样，获得云计算的好处可能是一个代价高昂的过程。下面将分享如何通过微服务原则、领域驱动的设计理念以及编码最佳实践的思考来成功实现微服务。云原生应用程序、Kubernetes实例和微服务都代表了一个分层系统。了解这些层使人们能够获得释放云计算和容器原生优势所需的洞察力。系统设计的本质系统设计是一种权衡取舍的游戏。当脱离组织环境时，许多架构决策在本质上并不正确或错误。对于制定决策的组织来说，好的建议是尽可能地扩大和构建决策，以便在一开始就理解决策。基本准则始终是将这些决策与组织的目标联系起来。在组织环境中，基本原则、实践和模式需要与组织的目标保持一致。基本面设定了实现目标的方向，而实践和模式代表了团队为实现这些目标将采取的实际步骤。例如，许多组织的目标可能是成为全球市场事实上的软件解决方案。其基本原则之一是实践持续交付，以确保高质量的生产部署并最大限度地减少潜在的代价高昂的事件。实践是团队特定的和特定的。为了支持组织的工程业务部门遵循的原则，可以让SRE团队实践事件管理，其中包括使用持续交付平台来跟踪或审计失败的部署。允许开发人员使用持续交付解决方案进行频繁发布或自助部署。组织开发团队的另一种做法是测试所有代码。虽然不可能知道每个决策在未来将如何影响整个系统，但组织所能做的最好的事情就是确定其目标以及基本原则和实践将如何帮助它实现这些目标。微服务微服务是协同工作的小型自治服务。松耦合和高内聚指的是微服务的两个概念。内聚是将相关代码组合在一起的方式，而耦合是不同服务之间相互依赖的方式。软件工程大师RobertC.Martin定义的“单一职责原则”是微服务的核心。它的定义是“将那些因相同原因而改变的事物聚集在一起，并将那些因不同原因而改变的事物聚集在一起”。分离。”这两个概念推动了微服务的七大原则，允许团队独立工作、部署、失败、交付和扩展。面向服务的架构(SOA)旨在解决大型单体应用程序、代码可重用性和维护方面的挑战。微服务是一种通过独立服务实现面向服务的架构(SOA)的方法，其中每个服务充当组织业务领域的边界。在微服务架构中，每个更改都可以彼此独立地实施和部署，而无需用户更改。微服务的原则使用微服务时，一个常见的故障点是过早分解。通常情况下，团队会因应用程序的用例发生代价高昂的更改，或者初始服务边界是错误的。将应用程序分解为微服务通常是开始微服务之旅的最简单方法。领域驱动设计原理领域驱动设计（DDD）是如何通过代码对现实世界进行建模。因此，领域驱动设计(DDD)介于优秀代码和微服务成功之间。尽管有很多文献讨论如何从战略和战术上实施领域驱动设计(DDD)，但如果没有实践和指导，这仍然是一个相当复杂的话题。以下是如何开始使用领域驱动设计(DDD)概念。首先必须明白，组织使用的任何代码都是从域中的问题和业务需求的问题开始的。因此，领域驱动设计的旅程始于领域专家和开发人员。通常一个组织可能有多个领域专家一个开发人员或多个开发人员但只有一个领域专家。无论组织结构如何，团队的目标都是放眼大局并创建所谓的场景图。在构建场景图时，组织可以通过了解问题空间、发现通用语言并为系统创建表示模型来提取领域知识。该系统由表示问题空间的域和子域组成。这些域在场景映射中称为场景，可以描述组织内的不同系统。例如，组织可能需要表示一个销售场景和一个客户支持场景，以便为处理食品包装厂的销售和客户支持的新软件应用程序建模。示例场景图这些领域让组织很好地了解如何创建有限的场景。有界场景表示属于系统的服务，为该模型封装和定义特定职责。创建有界场景就是建立一个边界，领域语言不会在该空间中引起混淆问题。定义有限的场景、通用语言和场景图可以让组织在使用微服务时专注于大局。领域驱动设计在讨论系统设计时指导开发人员，因为组织经常寻找通过代码表示现实世界的方法。领域驱动设计(DDD)对于刚接触特定领域的组织或开发人员，或者希望将其应用程序分解为微服务的组织特别有用。干净的代码对于微服务的成功来说，最后一个重要的事情是如何维护和使用您的组织的代码。有许多建议鼓励持久且易于理解的企业代码库。其中一些引入了额外的权衡，但一般的经验法则是避免对不断增长的代码库感到自满，并寻找适合您组织的实践。提供共享库。跨领域、行业、团队和各种代码库重复使用的方法非常适合共享库。第三方或自定义库是让您的代码库得到良好管理和测试的好方法，尤其是当组织继续在域内开发更多功能和服务时。不建议为频繁更改的代码引入自定义库。自定义库会添加应用程序依赖项，库的更新会迫使消费者重新部署。受信任或成熟的第三方库通常是很好的资源，可以避免与自定义库相关的一些维护和不稳定性。强制模块化分离。人们经常听到有关模块化隔离的建议，但由于更改的性质，它在实践中往往会失败。随着新功能、开发人员和流程被引入代码库，人们构建提供这些功能的模块和文件的方式也发生了变化。保持每个模块和文件的大小合适也很重要。作为指南，在团队基础上设置一些实践来指导组织如何在代码库中组织业务逻辑。一些团队具有三个组织层，包括表示层、逻辑层和数据层。此策略可确保业务逻辑不会在应用程序逻辑中丢失。实施代码的模块化分离还可以帮助团队成功实施领域驱动设计(DDD)。保持你的代码库小。之前的建议都导致维护更小的代码库。但是，围绕保持代码库精简和小型化经常出现的一个常见问题是有多小？在许多方面，小型代码库成为一种反模式，因为团队无法理解他们的服务如何跨系统工作场景中提供了业务责任。同样，对于大型代码库，团队将难以分散决策制定、理解他们的代码库以及响应其他形式的变化。这两个挑战的一个关键指标是问题的增加。维护干净的代码库是域驱动设计(DDD)、微服务以及编写Kubernetes或云原生应用程序不可或缺的一部分。正如Kubernetes、微服务和领域驱动设计(DDD)影响组织设计代码的方式。希望这些解释能够说明它的应用程序是如何由相互重叠和互补的层组成的，从而形成一个高效和成功的系统。结论许多投资Kubernetes计划的组织都希望通过微服务取得成功。本文展示了如何成功使用微服务。拥有如此多的工具、流程和管理流程的原则可能很困难，尤其是当最终客户无法获得频繁的软件交付时。持续交付可帮助组织交付价值、管理微服务部署、定义发布和回滚策略，并降低微服务的总体成本。
