系统城推出微服务的成功应用

组织通过微服务基本准则、领域驱动的设计概念和编码优秀实践成功地使用微服务，可以充分利用Kubernetes/容器原生的优势。

行业专家参加了DevOps Institue日前在企业Kubernetes上进行的SkiLUp演讲。在一个名为“通过持续交付导航Kubernetes之旅”的会议中，行业讨论了企业Kubernetes的状态以及持续交付对于那些使用容器技术的组织的影响。其演讲的中心主题是Kubernetes如何为交付团队引入新的范例。

对于使用微服务的组织来说，其成功应用可能是多种多样的，从云计算中获益可能是一个代价高昂的过程。以下将分享如何通过微服务原理、领域驱动的设计概念以及有关编码优秀实践的注意事项来成功实现微服务。云原生应用程序、Kubernetes实例和微服务都代表了一个由层组成的系统。了解这些层使人们能够获得释放云计算和容器原生优势所需的见解。

系统设计的本质

系统设计是一个权衡的游戏。当脱离组织环境时，许多架构决策在本质上并不是对与错。组织做出决策的优秀建议是尽可能扩大决策范围和框架，以在初始时理解决策。其基本准则始终是将这些决策与组织的目标联系起来。在组织环境中，基本准则、实践和模式需要与组织的目标保持一致。基本准则为实现目标确定方向，而实践和模式代表团队为实现这些目标而采取的实际步骤。

例如，很多组织的目标可能是成为面向全球市场的事实上的软件解决方案。其基本原则之一就是实行持续交付，以确保高质量的生产部署并很大程度地减少可能造成高昂成本的事故。实践是针对团队的，并且是特定的。为了支持组织的工程业务部门遵循的原则，可以让SRE团队针对事件管理进行实践，其中包括使用持续交付平台来跟踪或审计失败的部署。可以让开发人员使用持续交付解决方案进行频繁的发布或自助部署。组织的开发团队的另一个实践是测试所有代码。

虽然不可能知道每一个决策在未来会对整个系统产生怎样的影响，但组织能做的最好的事情就是确定目标，以及基本原则和实践如何帮助其实现这些目标。

微服务

微服务是一种小型的、自主的、协同工作的服务。松散耦合和高内聚性是指微服务的两个概念。内聚性是将相关代码分组在一起的方式，而耦合性是指不同的服务如何相互依赖。软件工程大师RobertC.Martin对“单一责任原则”的定义是微服务的核心，它的定义是“将因相同原因而发生变化的那些事物聚集在一起，并将因不同原因而发生变化的那些事物分开。”

这两个概念推动了微服务的七个原则，允许团队独立地工作、部署、失败、交付和扩展。

面向服务的架构(SOA)旨在应对大型单片应用程序、代码的可重用性和维护方面的挑战。微服务是通过独立服务实现面向服务的架构(SOA)的一种方法，其中每个服务都充当组织业务领域的边界。在微服务架构中，每个更改都可以彼此独立地实现和部署，而无需用户更改。

微服务的原则

使用微服务时，常见的故障点是过早分解。在通常情况下，团队在与应用程序的用例相关的更改中会付出高昂的成本，或者初始服务边界是错误的。将应用程序分解为微服务通常是开始微服务之旅的最简单方法。

域驱动设计的原则

域驱动设计(DDD)是如何通过代码对现实世界进行建模。因此，域驱动设计(DDD)介于出色的代码和微服务成功之间。尽管有许多文献讨论了如何从战略和战术上实施域驱动设计(DDD)，但在没有实践和指导的情况下，这仍然是一个相当复杂的话题。以下是利用域驱动设计(DDD)概念的入门方法。

首先必须理解，组织使用的任何代码都始于存在于域中的问题以及存在业务愿望的问题。因此，领域驱动设计的旅程始于领域专家和开发人员。通常，组织可能有多位领域专家一名开发人员或各种开发人员，但只有一名领域专家。无论组织结构如何，团队的目标都是着眼于全局并创建所谓的场景地图。

构建场景映射时，组织可以通过了解问题空间、发现通用语言并为系统创建表示模型来提取领域知识。系统由代表问题空间的域和子域组成。这些域在场景映射中称为场景，并且可以描述组织内的不同系统。例如，组织可能需要表示一个销售场景和客户支持场景，以对处理食品包装厂的销售和客户支持的新软件应用程序进行建模。

示例场景映射

这些域为组织提供了有关如何创建有限场景的好主意。有界场景表示属于系统的服务，它封装并定义了该模型的特定职责。创建有界场景就是要建立一个边界，在这个边界中，域语言在这个空间中不会造成混淆的问题。

定义有限的场景、通用语言和场景映射可以使组织在使用微服务时专注于全局。域驱动设计指导开发人员讨论系统设计时，因为组织经常在寻找通过代码表示真实世界的方法。域驱动设计(DDD)对于不熟悉特定领域的组织或开发人员，或者对于希望将其应用程序分解为微服务的组织而言，域驱动设计(DDD)尤其有用。

清洁代码

微服务成功的最后一件事是如何维护和使用组织的代码。有许多建议可以鼓励持久和可理解的企业代码库。它们中的一些引入了额外的权衡，但通常的经验法则是避免对不断增长的代码库感到自满，并寻找对组织有用的做法。

• 提供共享库。跨领域、行业、团队和各种代码库重复的方法是共享库的理想选择。第三方库或自定义库是使代码库得到良好管理和测试的一种很好方法，尤其是当组织继续在域内开发更多功能和服务时。建议不要为频繁更改的代码引入自定义库。定制库添加了应用程序依赖项，其中对库的更新迫使使用者重新部署。受信任或成熟的第三方库通常是避免与自定义库相关的某些维护和不稳定的很好资源。
• 强制执行模块化分离。正如人们经常听到关于模块化隔离的建议一样，由于变更的性质，它在实践中经常失败。作为新功能，开发人员和流程已引入代码库，人们构造提供这些功能的模块和文件的方式也发生了变化。保持每个适当大小的模块和文件也很重要。作为准则，以团队为单位设置一些实践，以指导组织如何在代码库中组织业务逻辑。一些团队具有三个组织层，包括表示层、逻辑层和数据层。该策略确保业务逻辑不会在应用程序逻辑内丢失。强制执行代码的模块化分离也可以帮助团队成功实现域驱动设计(DDD)。
• 保持较小的代码库。以前的建议都会导致维护较小的代码库。但是，围绕使代码库保持精简和小型化经常会出现一个常见的问题，即小型化小到什么程度?在许多方面，小型代码库成为一种反模式，因为团队无法理解他们的服务在整个系统的场景中提供了业务责任。同样，对于大型代码库来说，团队将难以分散决策，了解其代码库，并应对其他形式的更改。这两个挑战的关键指标是问题的增加。

维护干净的代码库是域驱动设计(DDD)、微服务以及编写Kubernetes或云原生应用程序所不可或缺的。正如Kubernetes、微服务和域驱动设计(DDD)影响组织设计代码的方式一样。希望这些解释能够说明其应用程序是如何由相互重叠和互补的层组成的，从而形成一个有效且成功的系统。

结语

许多投资Kubernetes计划的组织都希望通过微服务获得成功。本文展示了如何通过微服务获得成功。拥有如此多的工具、流程和原则来管理流程可能会很困难，尤其是当最终客户无法获得频繁的软件交付时。持续交付可帮助组织交付价值、管理微服务部署、定义发布和回滚策略，并降低微服务的总体成本。