微服务架构设计方案.docx

"微服务架构设计方案" 微服务架构设计方案是当前软件架构领域非常热门的词汇。微服务架构的核心思想是，一个应用是由多个小的、相互独立的、微服务组成，这些服务运行在自己的进程中，开发和发布都没有依赖。 单体架构（Monolithic Architecture）是企业级应用的常见方式，会把大量功能堆积到同一个单体架构中去。单体架构的初期效率很高，应用会随着时间推移逐渐变大。在每次的迭代中，开发团队都会面对新功能，然后开发许多新代码，随着时间推移，这个简单的应用会变成了一个巨大的怪物。图 1：单体架构。 单体架构的应用一般有以下特点： * 设计、开发、部署为一个单独的单元。 * 会变得越来越复杂，最后导致维护、升级、新增功能变得异常困难。 * 很难以敏捷研发模式进行开发和发布。 * 部分更新，都需要重新部署整个应用。 * 水平扩展：必须以应用为单位进行扩展，在资源需求有冲突时扩展变得比较困难。 * 可用性：一个服务的不稳定会导致整个应用出问题。 * 创新困难：很难引入新的技术和框架，所有的功能都构建在同质的框架之上。 微服务架构的设计需要关心微服务的业务范围，而不是服务的数量和规模尽量小。数量和规模需要依照业务功能而定。微服务设计的关键问题包括： * 职责单一原则（Single Responsibility Principle）：把某一个微服务的功能聚焦在特定业务或者有限的范围内会有助于敏捷开发和服务的发布。 * 设计阶段就需要把业务范围进行界定。 * 需要关心微服务的业务范围，而不是服务的数量和规模尽量小。 * 于 SOA 不同，某个微服务的功能、操作和消息协议尽量简单。 微服务消息的机制需要更轻量的机制。同步消息就是客户端需要保持等待，直到服务器返回应答。REST 是微服务中默认的同步消息方式，它提供了基于 HTTP 协议和资源 API 风格的简单消息格式，多数微服务都采用这种方式。Thrift 是另外一个可选的方案。它采用接口描述语言定义并创建服务，支持可扩展的跨语言服务开发，所包含的代码生成引擎可以在多种语言中，如 C++, Java, Python, PHP 等。