可扩展架构

基本思想和模式

拆

面向流程拆分：将整个业务流程拆分为几个阶段，每个阶段作为一部分。

面向服务拆分：将系统提供的服务拆分，每个服务作为一部分。

面向功能拆分：将系统提供的功能拆分，每个功能作为一部分。

传统的可扩展架构模式：分层架构和SOA

分层架构

C/S架构、B/S架构

MVC架构、MVP架构

逻辑分层架构

SOA

面向服务的架构

SOA是把多个系统整合，而微服务是把单个系统拆开来

微服务架构

微服务和SOA的关系

• 微服务是SOA的实现方式

“微服务就是使用 HTTP RESTful 协议来实现 ESB 的 SOA”“使用 SOA 来构建单个系统就是微服务”和“微服务就是更细粒度的 SOA”。

• 微服务是去掉 ESB 后的 SOA

SOA 架构最广为人诟病的就是庞大、复杂、低效的 ESB，因此将 ESB 去掉，改为轻量级的 HTTP 实现，就是微服务。

• 微服务是一种和 SOA 相似但本质上不同的架构理念

服务粒度

SOA 的服务粒度要粗一些，而微服务的服务粒度要细一些。

服务通信

SOA 采用了 ESB 作为服务间通信的关键组件，负责服务定义、服务路由、消息转换、消息传递，总体上是重量级的实现。微服务推荐使用统一的协议和格式，例如，RESTful 协议、RPC 协议，无须 ESB 这样的重量级实现。

服务交付

微服务的架构理念要求“快速交付”，相应地要求采取自动化测试、持续集成、自动化部署等敏捷开发相关的最佳实践。

应用场景

SOA 更加适合于庞大、复杂、异构的企业级系统，这也是 SOA 诞生的背景。这类系统的典型特征就是很多系统已经发展多年，采用不同的企业级技术，有的是内部开发的，有的是外部购买的，无法完全推倒重来或者进行大规模的优化和重构。因为成本和影响太大，只能采用兼容的方式进行处理，而承担兼容任务的就是 ESB。

微服务更加适合于快速、轻量级、基于 Web 的互联网系统，这类系统业务变化快，需要快速尝试、快速交付；同时基本都是基于 Web，虽然开发技术可能差异很大（例如，Java、C++、.NET 等），但对外接口基本都是提供 HTTP RESTful 风格的接口，无须考虑在接口层进行类似 SOA 的 ESB 那样的处理。

微服务的陷阱

服务划分过细，服务间关系复杂。

服务数量太多，团队效率急剧下降。

调用链太长，性能下降

调用链太长，问题定位困难

没有自动化支撑，无法快速交付

没有服务治理，微服务数量多了后管理混乱

架构实践

方法

1. 服务发现、服务路由、服务容错：这是最基本的微服务基础设施。

2. 接口框架、API 网关：主要是为了提升开发效率，接口框架是提升内部服务的开发效率，API 网关是为了提升与外部服务对接的效率。

3. 自动化部署、自动化测试、配置中心：主要是为了提升测试和运维效率。

4. 服务监控、服务跟踪、服务安全：主要是为了进一步提升运维效率。

基础设施

自动化测试

自动化部署

配置中心

接口框架

api网关

服务发现

服务路由

服务容错

服务监控

服务追踪

服务安全

微内核架构

微内核架构也被成为插件化架构，是一种面向功能进行拆分的可扩展性架构。

基本架构

微内核架构包含两类组件：核心系统和插件模块。

核心系统功能比较稳定，不会因为业务功能扩展而不断修改，插件模块可以根据业务功能的需要不断的扩展。