|
微服务是一种软件架构模式，其核心思想是将复杂的应用程序拆分成一组小型、自治的服务单元。这些服务单元可以独立开发、部署、扩展和维护，每个服务都运行在其自己的进程中，并通过轻量级的通信机制（如HTTP API）相互通信。
微服务架构将单体应用分解为多个小型服务，每个服务都围绕特定的业务领域或功能进行构建，并且能够独立地运行和扩展。这种架构模式使得应用程序更加灵活、可维护，并且能够快速响应业务变化。
微服务的主要特点包括：
-
独立部署：每个微服务都可以独立地进行部署，这意味着可以在不影响其他服务的情况下对单个服务进行更新或修复。
-
独立扩展：由于服务是独立的，因此可以根据需要单独扩展某个服务，以满足更高的性能要求或处理更多的请求。
-
技术多样性：不同的服务可以使用不同的技术栈和开发语言，这使得团队可以根据具体需求选择最适合的技术。
-
易于开发和维护：由于每个服务都相对较小且独立，因此可以更容易地进行开发和维护。此外，每个服务都专注于特定的业务领域，使得代码更加清晰、易于理解。
-
高可用性：微服务架构支持高可用性和容错性，因为即使某个服务出现故障，其他服务仍然可以正常运行。
基于微服务的相关优点，在微服务开发的过程中，也会碰上对应的挑战，比如：
-
运维复杂性：随着服务数量的增加，运维人员需要管理更多的服务实例和依赖关系，这增加了运维的复杂性。
-
分布式系统问题：微服务架构是分布式系统，需要处理网络延迟、分布式事务和一致性问题等挑战。
-
服务间通信：服务间通信的复杂性和一致性需要仔细考虑，以确保系统的可靠性和性能。
对于流水线编排而言，重点考虑需要解决的是解决运维的复杂性。即对应服务实例的依赖关系，是否需要互相依赖，有前后顺序等。
通过父子POM文件方式，管理业务上耦合且有强依赖的代码工程
对于本身代码工程，有业务上耦合的，强依赖的，建议合并成一个代码库。通过父子POM文件的方式来管理项目的依赖、插件配置和属性。这种有助于保持项目结构的清晰和一致性。父POM文件通常包含一些共通的配置，比如项目的版本、依赖管理、插件管理等，而子项目（或称为模块）POM文件则继承自父POM，并可能添加一些特定的配置或依赖。
此种方式，可以将复杂的流水线前后依赖顺序编排进行简化，通过父子POM的方式，来决定代码编译的先后顺序。
如果业务上耦合程度不大，通过流水线的灵活流程控制能力来满足服务间的依赖关系
对于此类场景，首先需要先编排单条微服务的流水线，实现此代码工程的最基础的CI、CD功能，如下图：
通过此类流水线的代码拉取、静态代码扫描、编译构建、单元测试、镜像上传、部署等插件能力，来实现单条流水线的CI、CD。
在此基础上，编排面向此项目的总流水线，通过父子流水线与流水线流程控制的方式，来实现微服务流水线，总体编排，一次执行，多个服务发布的效果。
流程控制的效果如下：
通过“何时运行本JOB配置”来控制什么情况下需要执行子流水线，匹配对应流水线参数与对应处理脚本，完成上述目标。
| 
