当一个微服务依赖另外一个微服务时，需要先部署被依赖的微服务，确保其正常运行后再部署依赖它的微服务。
在部署依赖微服务时，需要配置正确的依赖关系和访问地址，以确保两个微服务之间能够正常通信和协作。同时，还需要进行测试和监控，确保整个系统的稳定性和可靠性。最后，需要及时更新和维护依赖关系，以保证整个微服务架构的健康发展。
微服务架构有六种模式，分别是。
1、聚合器微服务设计模式
聚合器调用多个服务实现应用程序所需的功能。它可以是一个简单的Web页面，将检索到的数据进行处理展示。它也可以是一个更高层次的组合微服务，对检索到的数据增加业务逻辑后进一步发布成一个新的微服务，这符合DRY原则。
2、代理微服务设计模式
在这种情况下，客户端并不聚合数据，但会根据业务需求的差别调用不同的微服务。代理可以仅仅委派请求，也可以进行数据转换工作。
3、链式微服务设计模式
这种模式在接收到请求后会产生一个经过合并的响应。
在这种情况下，服务A接收到请求后会与服务B进行通信，类似地，服务B会同服务C进行通信。所有服务都使用同步消息传递。在整个链式调用完成之前，客户端会一直阻塞。
4、分支微服务设计模式
5、数据共享微服务设计模式
自治是微服务的设计原则之一，就是说微服务是全栈式服务。但在重构现有的“单体应用（monolithicapplication）”时，SQL数据库反规范化可能会导致数据重复和不一致。
在这种情况下，部分微服务可能会共享缓存和数据库存储。不过，这只有在两个服务之间存在强耦合关系时才可以。对于基于微服务的新建应用程序而言，这是一种反模式。
6、异步消息传递微服务设计模式
虽然REST设计模式非常流行，但它是同步的，会造成阻塞。因此部分基于微服务的架构可能会选择使用消息队列代替REST请求/响应。
1 微服务项目的结构可以划分为三个部分：应用程序、服务和基础设施。2 应用程序是指提供实际业务价值的服务，可以包含多个微服务。服务是指执行特定任务的单个微服务，每个服务都有自己的职责和功能。基础设施是指支持微服务架构的各种工具和框架，包括服务发现、负载均衡、日志管理等。3 在微服务项目中，应该将应用程序和服务分离出来，使它们能够独立部署和扩展。同时，基础设施应该被视为一个单独的部分，以便更好地管理和维护。对于服务的划分，应该根据业务逻辑和职责来进行，每个服务应该尽可能地独立和自治。
微服务平台的开发需要视项目的实际规模而定。
正常微服务必备的几个岗位人员：
负责整个微服务技术架构的搭建与维护
因为微服务需要根基业务的实际场景进行业务的拆分，所以需要产品对各模块进行分析后拆分服务。
负责核心服务代码的编写以及每个模块交互的编写，保证服务的稳步实施。
微服务一般带来前后端分离，所以至少要两个人员，前段和后端。
微服务架构：微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制(通常用HTTP资源API)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。