您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

微服务体系结构样式Microservices architecture style

微服务体系结构由一系列小型的自治服务组成。A microservices architecture consists of a collection of small, autonomous services. 每个服务都是自包含服务,并且应实现单个业务功能。Each service is self-contained and should implement a single business capability.

微服务体系结构样式的逻辑图

什么是微服务?What are microservices?

  • 微服务具有规模小、独立和松散耦合的特点。Microservices are small, independent, and loosely coupled. 一个小规模的开发人员团队就能编写和维护一个服务。A single small team of developers can write and maintain a service.

  • 每个服务都是一个单独的基本代码,可由小型开发团队管理。Each service is a separate codebase, which can be managed by a small development team.

  • 服务可独立部署。Services can be deployed independently. 团队可以更新现有服务,而无需重新生成和重新部署整个应用程序。A team can update an existing service without rebuilding and redeploying the entire application.

  • 服务负责暂留自己的数据或外部状态。Services are responsible for persisting their own data or external state. 这一点与传统模型不同,后者由单独的数据层处理数据暂留。This differs from the traditional model, where a separate data layer handles data persistence.

  • 服务通过定义完善的 API 相互通信。Services communicate with each other by using well-defined APIs. 每个服务的内部实现细节均对其他服务隐藏。Internal implementation details of each service are hidden from other services.

  • 服务无需共享相同的技术堆栈、库或框架。Services don't need to share the same technology stack, libraries, or frameworks.

除了服务本身,典型微服务体系结构中还会出现其他组件:Besides for the services themselves, some other components appear in a typical microservices architecture:

管理/业务流程.Management/orchestration. 该组件负责将服务放置在节点上、确定故障,以及跨节点重新均衡服务等等。This component is responsible for placing services on nodes, identifying failures, rebalancing services across nodes, and so forth. 该组件通常是一种现成的技术(例如 Kubernetes),而不是自定义构建的内容。Typically this component is an off-the-shelf technology such as Kubernetes, rather than something custom built.

API 网关API Gateway. API 网关是客户端的入口点。The API gateway is the entry point for clients. 客户端会调用 API 网关,网关再将调用转发到后端上的相应服务,而不是由客户端直接调用服务。Instead of calling services directly, clients call the API gateway, which forwards the call to the appropriate services on the back end.

使用 API 网关的优点如下:Advantages of using an API gateway include:

  • 它分离了客户端与服务。It decouples clients from services. 无需更新所有客户端,便可对服务进行版本控制或重构。Services can be versioned or refactored without needing to update all of the clients.

  • 服务可以使用对 Web 不友好的消息传递协议,比如 AMQP。Services can use messaging protocols that are not web friendly, such as AMQP.

  • API 网关可执行身份验证、日志记录、SSL 终止和负载均衡等其他跨领域功能。The API Gateway can perform other cross-cutting functions such as authentication, logging, SSL termination, and load balancing.

优点Benefits

  • 敏捷性。Agility. 由于微服务是独立部署的,因此我们可以更轻松地管理 bug 修复和功能发布。Because microservices are deployed independently, it's easier to manage bug fixes and feature releases. 无需重新部署整个应用程序即可更新服务,出现问题时可回滚更新。You can update a service without redeploying the entire application, and roll back an update if something goes wrong. 在很多传统应用程序中,如果在应用程序的一个部件中发现 bug,它会阻止整个发布流程。In many traditional applications, if a bug is found in one part of the application, it can block the entire release process. 新功能可能会被搁置,要等到 bug 修补程序后才能进行集成、测试和发布。New features may be held up waiting for a bug fix to be integrated, tested, and published.

  • 小型专属团队Small, focused teams. 微服务应该足够小,单个功能团队就能构建、测试和部署。A microservice should be small enough that a single feature team can build, test, and deploy it. 即使团队规模不大,也能大幅提升敏捷性。Small team sizes promote greater agility. 而由于沟通效率更慢、管理开销更高且敏捷性更低,大型团队的工作效率往往更低。Large teams tend be less productive, because communication is slower, management overhead goes up, and agility diminishes.

  • 小型代码库Small code base. 在整体式应用程序,代码依赖项往往会随着时间的推移而变得混杂。因此,要在多个位置更改代码才能添加新功能。In a monolithic application, there is a tendency over time for code dependencies to become tangled Adding a new feature requires touching code in a lot of places. 如果不共享代码或数据存储,则微服务体系结构可将依赖项减到最少,使新功能的添加变得更容易。By not sharing code or data stores, a microservices architecture minimizes dependencies, and that makes it easier to add new features.

  • 混合技术Mix of technologies. 团队可以选择最适合其服务的技术,并适当地使用混合技术栈。Teams can pick the technology that best fits their service, using a mix of technology stacks as appropriate.

  • 错误隔离Fault isolation. 单个微服务在不可用的情况下不会中断整个应用程序,但前提是所有上游微服务能够正确处理故障(例如,通过实施熔断机制)。If an individual microservice becomes unavailable, it won't disrupt the entire application, as long as any upstream microservices are designed to handle faults correctly (for example, by implementing circuit breaking).

  • 可伸缩性Scalability. 服务可独立扩展,这样你就能横向扩展需要更多资源的子系统,而不横向扩展整个应用程序。Services can be scaled independently, letting you scale out subsystems that require more resources, without scaling out the entire application. 借助 Kubernetes 或 Service Fabric 等业务流程协调程序,你可将更高密度的服务打包到一台主机中,从而提高资源的利用效率。Using an orchestrator such as Kubernetes or Service Fabric, you can pack a higher density of services onto a single host, which allows for more efficient utilization of resources.

  • 数据隔离Data isolation. 执行架构更新要容易得多,因为只会影响单个微服务。It is much easier to perform schema updates, because only a single microservice is affected. 在整体应用程序中,更新架构可能极具挑战性,因为应用程序的不同部分可能都要获取相同的数据,对架构进行任何更改都会带来风险。In a monolithic application, schema updates can become very challenging, because different parts of the application may all touch the same data, making any alterations to the schema risky.

挑战Challenges

微服务的优势并非没有代价。The benefits of microservices don't come for free. 下面是在开始使用微服务体系结构之前需要考虑的一些挑战。Here are some of the challenges to consider before embarking on a microservices architecture.

  • 复杂性Complexity. 与同等的单一式应用程序相比,微服务应用程序具有更多移动部件。A microservices application has more moving parts than the equivalent monolithic application. 每个服务更简单,但整个系统作为整体来说更复杂。Each service is simpler, but the entire system as a whole is more complex.

  • 开发和测试Development and testing. 编写依赖于其他独立服务的小型服务时需要的方法与编写传统的整体式或分层式应用程序时的方法不同。Writing a small service that relies on other dependent services requires a different approach than a writing a traditional monolithic or layered application. 现有工具并非总是能够处理服务依赖关系。Existing tools are not always designed to work with service dependencies. 跨服务边界进行重构可能很困难。Refactoring across service boundaries can be difficult. 测试服务依赖关系也有一定难度,尤其是在应用程序快速发展之时。It is also challenging to test service dependencies, especially when the application is evolving quickly.

  • 缺乏监管Lack of governance. 用于生成微服务的分散式方法具有一定优势,但也可能导致许多问题。The decentralized approach to building microservices has advantages, but it can also lead to problems. 用户在生成过程中可能采用了许多不同的语言和框架,从而使应用程序变得难以维护。You may end up with so many different languages and frameworks that the application becomes hard to maintain. 这种情况下可以实施一些项目范围内的标准,不过分限制团队的灵活性。It may be useful to put some project-wide standards in place, without overly restricting teams' flexibility. 这尤其适用于日志记录等跨领域功能。This especially applies to cross-cutting functionality such as logging.

  • 网络拥塞和延迟Network congestion and latency. 使用大量小型的精细服务可能会增加服务间的通信量。The use of many small, granular services can result in more interservice communication. 此外,如果服务依赖关系链变得太长(服务 A 调用 B,B 调用 C...),额外延迟可能会成为一个问题。Also, if the chain of service dependencies gets too long (service A calls B, which calls C...), the additional latency can become a problem. 用户需要精心设计 API。You will need to design APIs carefully. 应避免过于繁琐的 API,考虑使用序列化格式,并找到可以使用异步通信模式的地方。Avoid overly chatty APIs, think about serialization formats, and look for places to use asynchronous communication patterns.

  • 数据完整性Data integrity. 每个微服务负责自己的数据暂留。With each microservice responsible for its own data persistence. 因此,数据一致性可能是个挑战。As a result, data consistency can be a challenge. 如果可能,请采用最终一致性。Embrace eventual consistency where possible.

  • 管理Management. 成功使用微服务需要有成熟的 DevOps 区域性。To be successful with microservices requires a mature DevOps culture. 跨服务的关联日志记录可能很难。Correlated logging across services can be challenging. 通常情况下,日志记录必须为单个用户操作关联多个服务调用。Typically, logging must correlate multiple service calls for a single user operation.

  • 版本控制Versioning. 对某个服务的更新不应中断依赖于它的其他服务。Updates to a service must not break services that depend on it. 多个服务可在任意给定时间更新,因此,若不精心设计,可能会遇到向后或向前兼容性问题。Multiple services could be updated at any given time, so without careful design, you might have problems with backward or forward compatibility.

  • 技能集Skillset. 微服务是一种高度分布式系统。Microservices are highly distributed systems. 请仔细评估团队是否具有成功使用微服务所需的技能和经验。Carefully evaluate whether the team has the skills and experience to be successful.

最佳做法Best practices

  • 围绕业务域对服务建模。Model services around the business domain.

  • 分散所有资源。Decentralize everything. 单个团队负责设计和生成服务。Individual teams are responsible for designing and building services. 避免共享代码或数据架构。Avoid sharing code or data schemas.

  • 拥有数据的服务应当有专用的数据存储。Data storage should be private to the service that owns the data. 为每个服务和数据类型使用最合适的存储。Use the best storage for each service and data type.

  • 服务通过设计完善的 API 进行通信。Services communicate through well-designed APIs. 避免泄露实现细节。Avoid leaking implementation details. API 应对域建模,而不是对服务的内部实现建模。APIs should model the domain, not the internal implementation of the service.

  • 避免服务之间耦合。Avoid coupling between services. 耦合的原因包括共享的数据库架构和严格的通信协议。Causes of coupling include shared database schemas and rigid communication protocols.

  • 将身份验证和 SSL 终止等跨领域操作分流到网关。Offload cross-cutting concerns, such as authentication and SSL termination, to the gateway.

  • 让网关不必了解域。Keep domain knowledge out of the gateway. 网关应处理和路由客户端请求,而无需了解业务规则或域逻辑。The gateway should handle and route client requests without any knowledge of the business rules or domain logic. 否则,网关会变成一个从属物,从而导致服务之间耦合。Otherwise, the gateway becomes a dependency and can cause coupling between services.

  • 服务应具有松散耦合和高功能内聚的特点。Services should have loose coupling and high functional cohesion. 应当将可能会一起更改的函数打包并部署在一起。Functions that are likely to change together should be packaged and deployed together. 如果它们驻留在不同的服务中,这些服务最终会紧密耦合,因为一个服务中的更改将需要更新其他服务。If they reside in separate services, those services end up being tightly coupled, because a change in one service will require updating the other service. 两个服务之间的通信过于频繁可能是紧密耦合和低内聚的征兆。Overly chatty communication between two services may be a symptom of tight coupling and low cohesion.

  • 隔离故障。Isolate failures. 使用复原策略可防止某个服务中的故障级联。Use resiliency strategies to prevent failures within a service from cascading. 请参阅复原模式设计可靠的应用程序See Resiliency patterns and Designing reliable applications.

后续步骤Next steps

有关在 Azure 上构建微服务体系结构的详细指导,请参阅在 Azure 中设计、构建和操作微服务For detailed guidance about building a microservices architecture on Azure, see Designing, building, and operating microservices on Azure.