服务架构掌中宝：微服务与应用架构指南

需积分: 3 156 浏览量更新于2024-08-02 收藏 527KB PDF 举报

"Service Architecture Pocket Guide.pdf 是一本关于服务架构的袖珍指南，属于Application Architecture Pocket Guide系列。这本书可能涵盖了如何设计、构建和管理服务架构的相关知识，旨在帮助读者理解和应用服务架构在实际IT项目中的关键概念。" 服务架构是现代软件开发中的一种重要模式，它强调将复杂的应用程序分解为一组可独立部署、可重用的服务。在"Service Architecture Pocket Guide"中，可能详细介绍了以下几个关键知识点： 1. **服务定义和服务模型**：书中可能会介绍服务的定义，包括服务的特性（如接口、边界、交互方式等），以及如何通过服务模型来组织和表示服务间的相互关系。 2. **服务设计原则**：遵循的设计原则通常包括可重用性、松耦合、自治性、可发现性等，这些原则有助于提高系统的灵活性、可扩展性和维护性。 3. **服务分类**：服务可以分为不同的类型，如业务服务、数据服务、功能服务等，书中可能详细解释了这些服务的区别和应用场景。 4. **服务接口和协议**：书中可能讨论了各种服务通信协议（如SOAP、REST、gRPC等）和接口设计的最佳实践，以确保服务之间的有效交互。 5. **服务发现与注册**：服务发现机制允许客户端找到并使用服务，而服务注册则是服务生命周期管理的关键部分，书中可能阐述了如何实现这一过程。 6. **服务治理**：服务治理涉及服务的质量保证、版本控制、安全性和性能监控，书中可能会提供关于如何实施有效服务治理策略的指导。 7. **微服务架构**：微服务是服务架构的一种常见形式，可能深入探讨了微服务的原理、优势、挑战以及如何进行微服务拆分。 8. **容器化与编排**：随着Docker和Kubernetes等技术的普及，书中可能介绍了如何利用这些工具来部署和管理服务，以实现更高的灵活性和可移植性。 9. **服务集成与编排**：书中可能讲解了如何通过API网关、ESB（企业服务总线）或其他工具来集成和协调多个服务，实现复杂的业务流程。 10. **容错与弹性**：在分布式系统中，服务的容错性和弹性至关重要，可能会介绍如何设计服务以应对故障，如使用断路器模式、重试策略等。 11. **安全性**：服务安全包括身份验证、授权、加密等，书中可能详细阐述了保护服务免受攻击和滥用的安全措施。 12. **监控与日志**：有效的监控和日志记录对于理解服务性能和诊断问题至关重要，书中可能提到了相关的工具和技术。最后，由于这是一本指南，可能还包含了实例和最佳实践，以帮助读者将理论知识应用到实际项目中。同时，书中强调了尊重知识产权，未经许可，不应复制或传播文档内容。微软公司可能拥有与该文档内容相关的专利、商标、版权或其他知识产权，除非有书面许可，否则不得擅自使用。

• Ensure that the service can manage messages arriving out of order (commutativity). If

there is a possibility that messages may arrive out of order, implement a design that will

store messages and then process them in the correct order.

SOA Services

• Design services to be application-scoped and not component-scoped. Service operations

should be coarse-grained and focused on application operations. For example, with

demographics data you should provide an operation that returns all of the data in one call.

You should not use multiple operations to return sub-sets of the data with multiple calls.

• Decouple the interface from the implementation. In an SOA application, it is very

important to keep internal business entities hidden from external clients. In other words,

you should never define a service interface that exposes internal business entities. Instead,

the service interface should be based on a contract that external consumers interact with.

Inside the service implementation, you translate between internal business entities and

external contracts.

• Design services with explicit boundaries. A services application should be self-contained

with strict boundaries. Access to the service should only be allowed through the service

interface layer.

• Design services to be autonomous. Services should not require anything from consumers of

the service, and should not assume who the consumer is. In addition, you should design

services with the assumption that malformed requests will be sent to it.

• Design compatibility based on policy. The service should publish a policy that describes

how consumers can interact with the service. This is more important for public services,

where consumers can examine the policy to determine interaction requirements.

Data Services

• Avoid using services to expose individual tables in a database. This will lead to chatty

service calls and interdependencies between service operations, which can lead to

dependency issues for consumers of the service.

• Do not implement business rules with data services. Different consumers of the data will

have unique viewpoints and rules. Attempting to implement rules in data access services

will impose restrictions on the use of that data.

Workflow Services

• Use interfaces supported by your workflow engine. Attempting to create custom interfaces

can restrict the type of operations supported, and will increase the effort required to

extend and maintain the services.

• Design a service that is dedicated to supporting workflow. Instead of adding workflow

services to an existing service application, consider designing an autonomous service that

supports only workflow requirements.

Service Architecture Pocket Guide

Microsoft patterns & practices

Services Application Frame

The following table lists the key areas to consider as you develop services architecture. Use the

key issues in the table to understand where mistakes are most often made. The sections

following this table provide guidelines for each of these areas.

Area

Key Issues

Authentication and

Authorization

• Lack of Authentication across trust boundaries.

• Lack of Authorization across trust boundaries.

•

Granular or improper authorization.

Communication

• Incorrect choice of transport protocol.

• Chatty communication with the service.

• Failing to protect sensitive data.

Data Consistency

• Failing to check data for consistency.

•

Improper handling of transactions in a disconnected model.

Exception Management

• Not catching exceptions that can be handled.

• Not logging exceptions.

• Compromising message integrity when an exception occurs.

Message Construction

• Not appreciating that message contents may be time-sensitive.

• Incorrect message construction for the operation.

•

Passing too much data in a single message.

Message Endpoint

• Not supporting idempotent operations.

• Implementing filters to handle specific messages.

•

Subscribing to an endpoint while disconnected.

Message Protection

•

Not protecting sensitive data.

• Using transport layer protection for messages that cross multiple

servers.

• Not considering data integrity.

Message Transformation

• Unnecessary use of transformations.

• Implementing transformations at the wrong location.

• Using a canonical model when not necessary.

Message Exchange Patterns

• Using complex patterns when not necessary.

•

Using the Request/Response pattern for one-way messages.

REST

•

Providing limited schema support.

• Not appreciating that tools for REST are primitive.

• Using hypertext to manage state.

SOAP

• Not choosing the appropriate security model.

• Not planning for fault conditions.

•

Using complex types in the message schema.

Validation

• Not validating message structures sent to the service.

• Failing to validate data fields associated with the message.

Authentication

The design of an effective authentication strategy for your service depends on the type of

service host you are using. If the service is hosted in IIS, you can take advantage of the

Service Architecture Pocket Guide

Microsoft patterns & practices

authentication support provided by IIS. If the service is hosted using a Windows Service or a

console application, you must use message-based authentication.

When designing an authentication strategy, consider following guidelines:

• Identify a suitable mechanism for securely authenticating users.

• Consider the implications of using different trust settings for executing service code.

• Ensure that secure protocols such as SSL are used with basic authentication, or when

credentials are passed as plain text.

• Use secure mechanisms such as WS Security with SOAP messages.

Authorization

Designing an effective authorization strategy is important for the security and reliability of your

service application. Failing to design a good authorization strategy can leave your application

vulnerable to information disclosure, data tampering, and elevation of privileges.

When designing an authorization strategy, consider following guidelines:

• Set appropriate access permissions on resources for users, groups, and roles.

• Use URL authorization and/or file authorization when necessary.

• Where appropriate, restrict access to publicly accessible service methods using declarative

principle permission demands.

• Execute services under the most restrictive account that is appropriate.

Communication

When designing the communication strategy for your service application, the protocol you

choose should be based on the deployment scenario your service must support. If the service

will be deployed within a closed network, you can use TCP for more efficient communication. If

the service will be deployed in to a public facing network, you should choose the HTTP protocol.

When designing a communication strategy, consider following guidelines:

• Determine how to reliability handle unreliable or intermittent communication.

• Use dynamic URL behavior with configured endpoints for maximum flexibility.

• Validate endpoint addresses in messages.

• Determine how to handle asynchronous calls.

• Decide if message communication must be one-way or two-way.

Exception Management

Designing an effective exception management strategy is important for the security and

reliability of your service application. Failing to do so can leave your application vulnerable to

denial of service (DoS) attacks, and may also allow it to reveal sensitive and critical information.

Raising and handling exceptions is an expensive operation, and it is important that the design

take into account the impact on performance. A good approach is to design a centralized

Service Architecture Pocket Guide

Microsoft patterns & practices

剩余59页未读，继续阅读

testi

粉丝: 1
资源: 6

服务架构掌中宝：微服务与应用架构指南

RIA_Architecture_Pocket_Guide.pdf

Microsoft Application Architecture Guide.pdf

Microsoft.Press.Microsoft.Application.Architecture.Guide.2nd.Edition.Nov.2009.rar

N-Layered.Domain-Oriented.Architecture.Guide.with.NET.4.0

KeyStone Architecture EMIF16 User Guide.pdf

Power Architecture Processors Getting Started Guide.pdf

Wiley.Publishing.Professional.Linux.Kernel.Architecture.2008.pdf

ARM Architecture Reference Manual.pdf

Software Architecture and Architect.pdf

EE Architecture and DoIP.pdf

最新资源