好玩的网站列表

1. 可扩展架构的基本思想和模式

软件系统与硬件/建筑系统最大的差异在于软件是可扩展的，会不断更新，不断发展。如何避免扩展时改动范围太大，是软件架构可扩展性设计的主要思考点。

1.1 基本思想 - 拆分

将大系统细分为小系统，扩展时只是修改其中一部分即可，无须整个系统到处都改，通过这种方式来减少改动范围，降低改动风险。

不同的拆分方式，本质上决定了系统的扩展方式

1.1.1 面向流程拆分 - 分层架构

将整个业务流程分为几个阶段，每个阶段作为一部分

扩展时大部分情况只需要修改一层，或者相关联的两层，不会出现所有层都需要修改的情况的。

1.1.2 面向服务拆分 - SOA，微服务

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

扩展时只需要扩展相关服务即可。

1.1.3 面向功能拆分 - 微内核架构

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

扩展时只需要扩展相关功能即可

2. 分层架构

N层架构，逻辑上的分层

2.1 C/S, B/S架构

划分的对象是整个业务系统，划分的维度是用户交互，将和用户交互的部分独立为一层，支撑用户交互的后台作为另外一层。

2.2 MVC, MVP架构

划分的对象是单个业务子系统，划分的维度是职责，将不同的职责划分到独立层，但各层的依赖关系会相对比较灵活。

2.3 逻辑分层架构

划分的对象可以是单个业务子系统，也可以是整个业务系统，划分的维度也是职责。虽然都是基于职责划分，但是不同点在于逻辑分层架构中的层是自顶向下依赖的。

2.4 分层架构的核心

保证各层之间的差异足够清晰，边界足够明显，让人看到架构图之后就能看懂整个架构。

分层架构能够较好支撑系统扩展的本质在于隔离关注点，即每层的组件只会处理本层的逻辑，这样可以支撑系统在某层上快速扩展。

要保证层与层之间的依赖是稳定的。

分层结构的另外一个特点是层层传递，即一旦分层确定，整个业务流程就会按照层进行依次传递，不能在层之间进行跳跃。

3. SOA & 微服务

3.1 SOA - Service Oriented Architecture - 面向服务的架构

提出的背景是企业内部的IT系统重复建设并且效率极低的问题，SOA提出了几个关键概念

3.1.1 服务

所有业务功能都是一项服务，意味着要对外提供开放的能力，当其他系统需要使用这项功能时，不需要做定制化开发。

3.1.2 ESB

Enterprise Service Bus - 企业服务总线. 屏蔽异构系统对外提供各种不同的接口方式，以此达到服务间高效的互联互通。

ESB功能强大，但是现实中的协议种类很多，如JMS，WS，HTTP，RPC等，数据格式也多种多样，转换的过程是需要耗费大量计算性能的，当ESB承载的消息太多时，ESB本身会成为整个系统的性能瓶颈。

3.1.3 松耦合

减少各个服务间的依赖和互相影响。

3.2 MicroService - 微服务

3.2.1 微服务与SOA的关系

• 微服务与SOA相似但是本质上并不相同
  • 是否有ESB
    • 微服务推荐使用同一的协议和格式
      • 例如RESTful协议， RPC协议
  • 服务的粒度
    • 微服务的服务粒度相对较细
  • 服务交付
    • 微服务架构理念是快速交付，相应的就要求采取自动化测试，持续集成，自动化部署等敏捷开发相关的最佳实践。
  • 应用场景
    • SOA更适合于庞大、复杂、异构的企业化系统
    • 微服务更适合于快速，轻量级，基于Web的互联网系统

3.2.2 微服务的陷阱

• 服务划分过细，服务间关系复杂
• 服务数量太多，团队效率急剧下降
• 调用链太长，性能下降
  • 一般线上的业务接口之间的调用，平均响应时间大约为50毫秒
• 调用链太长，问题定位困难
• 需要自动化的支撑以实现快速交付

4. 微服务架构最佳实践

4.1 方法论

4.1.1 人员分配

• 3个人负责一个微服务

4.1.2 拆分逻辑的方法

• 基于业务逻辑拆分
  • 将业务模块按照职责范围识别出来，每个单独的业务模块拆分为一个独立的服务
  • 拆分粒度的考虑 - 看人数最好
• 基于可扩展拆分
  • 将系统中的业务模块按照稳定性排序
    • 稳定服务
    • 变动服务
  • 这样做的目的是为了提升项目快速迭代的效率，避免在开发的时候，不小心影响了已有的成熟功能导致线上的问题。
• 基于可靠性拆分
  • 将业务模块按照优先级顺序排序，将可靠性要求高的核心服务和可靠性要求低的非核心服务拆分，然后重点保证核心服务的高可用
• 基于性能拆分
  • 将性能要求高或者性能压力大的模块拆分出来，避免影响其他服务器

    4.2 基础设施

• 服务发现、服务路由、服务容错
• 接口框架、API网关
• 自动化部署、自动化测试、配置中心
• 服务监控、服务跟踪、服务安全

4.2.1 自动化测试

• 代码级的单元测试
• 单个系统级的集成测试
• 系统间的接口测试

4.2.2 自动化部署

• 版本管理
• 资源管理
• 部署操作
• 回退操作

4.2.3 配置中心

• 统一的配置中心来管理所有微服务节点的配置
• 配置中心包括
  • 版本管理
  • 增删改查配置
  • 结点管理
  • 配置同步
  • 配置推送

4.2.4 接口框架

除了统一接口协议，还要统一接口传递的数据格式

4.2.5 API网关

内部微服务是相互连通的，相互访问都是点对点的。如果外部系统想调用系统的某个功能，也采取点对点的方式，那么外部系统会很崩，因为其无法理解这么多微服务的职责分工和边界，它只会关注其所需要的能力，而不会关注这个能力应该由哪个微服务提供。

====》 微服务需要一个统一的API网关，负责外部系统的访问操作

API网关是外部系统访问的接口，所有的外部系统接入系统都需要通过API网关，主要包括：

• 接入鉴权 - 是否允许接入
• 权限控制 - 可以访问哪些功能
• 传输加密
• 请求路由
• 流量控制

4.2.6 服务发现

• 自理式结构
  • 每个微服务自己完成服务发现
• 代理式
  • 微服务之间有一个负载均衡系统，有负载均衡系统来完成微服务之间的服务发现

4.2.7 服务容错

• 请求重试
• 流量控制
• 服务隔离

4.2.8 服务监控

• 实时搜集信息并进行分析，避免故障后再来分析，减少了处理时间
• 在实时分析的基础上进行预警，在问题萌芽的阶段发觉并预警，降低问题的影响范围和影响时间

4.2.9 服务跟踪

对于单个请求的完整跟踪，记录单个请求的发起时间，响应时间，响应错误码，请求参数，返回的JSON对象等信息。

4.2.10 服务安全

• 接入安全
• 数据安全
• 传输安全

5. 微内核架构

也被称为插件化架构(Plug-in Architecture), 是一种面向功能进行拆分的可扩展性架构。

5.1 基本架构

• 核心系统
  • 负责和具体业务功能无关的通用功能，例如模块加载，模块间通信
• 插件模块
  • 负责实现具体的业务逻辑

微内核架构本质就是将变化的部分封装在插件里面，从而达到快速灵活扩展的目的，而又不会影响整体系统的稳定。

5.2 设计关键点

5.2.1 插件管理

通过插件注册表，来知道当前有哪些插件，如何加载以及何时加载。插件注册表含有每个插件模块的信息，包括其名字，位置，加载时机等。

5.2.2 插件连接

插件是如何连接到核心系统的。

常见连接机制：

• OSGi
• 消息模式
• 依赖注入
• 分布式协议 RPC， HTTP

5.2.3 插件通信

实际应用当中会出现某个业务流程需要多个插件协作，这就要求两个插件之间进行通信。由于插件之间没有直接的联系，通信必须通过核心系统，因此核心系统需要提供插件通信机制。

5.3 OSGi框架

该框架为通过网络向设备提供服务建立开发的标准。该框架的初始目标是构建一个在广域网和局域网或设备上展开业务的基础平台，但因为其的动态化，热拔插，高可复用性的特点，成为了首选的插件化标准。

5.3.1 模块层 (Module)

模块层实现插件管理功能，插件被称为Bundle，每个Bundle是一个Java的JAR文件。模块层里含有所有的插件。

5.3.2 生命周期层 (Lifecycle)

实现插件连接功能，提供了执行时的模块管理，模块对底层OSGi框架的访问。生命周期层精确定义了Bundle生命周期的操作(安装、更新、启动、停止、卸载)，Bundle必须按照规范实现各个操作。

5.3.3 服务层 (Service)

服务层实现插件通信的功能。OSGi提供了一个服务注册的功能，用于插件将自己能提供的服务注册到OSGi核心的服务注册中心当中，如果某个服务想用其他服务，则直接在服务注册中心搜索可用服务中心即可。

---

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 stone2paul@gmail.com