04 可扩展

Posted 2021-03-12 moveofgod

基本思想: 拆

面向流程拆分，面向服务拆分，面向功能拆分

面向流程拆分：分层架构

展示层: 负责页面设计

业务层: 负责业务逻辑

数据层: 负责数据访问

存储层: 负责数据存储

面向服务拆分: SOA, 微服务

注册服务，登录服务，信息管理服务，安全设置服务

面向功能拆分: 微内核架构

手机号注册，手机号登录，基本信息管理，修改密码，身份证注册，身份证登录，课程信息管理。。。。。。

 

分层架构

C/S, B/S, MVC 

例如应用程序一般的分层: 从上到下

1层: 应用程序 （主界面，联系人）

2层：应用程序架构（活动管理器，窗口管理器）

3层：库 比如 SQLite

4层：linux 内核 （实际上在这之上还应该有 shell）

无论采用何种分层维度，分层架构设计最核心的一点就是需要保证各层之间的差异足够清晰， 边界足够明显，让人能够看懂。

SOA架构 (很像我们需要的)

SOA: service Oriented Architecture. 面向服务架构。

主要的核心思想就是将那些 cross function 独立出来做成服务. 而不是每个app 都有相同的 function 而重复造轮子.

微服务

为何有了 SOA 还要提微服务？

微服务是 SOA 的实现方式, 微服务是更细粒度的SOA. 都是通过服务拆分来解决可扩展问题。

微服务的“坑”

服务拆分过细，过分强调"small"

微服务基础设施不健全，忽略了“automated”, 没有自动化的支持，例如不能自动提交，部署

微服务越来越多，导致它并不“lightweight”，规模大了，实际上就不适合微服务了。微服务的粒度最好是3个人负责一个微服务的开发.

automated 的微服务，微服务基础设施

 

接口框架: HTTP / RPC, 并且数据格式用 JSON.

API网关: 微服务内部之间是互通的，相互之间都是点对点的，但是外部系统想调用服务，外部系统不需要知道内部的微服务职责划分与边界，它只关注这个系统整体的服务的能力。另外，外部系统访问还涉及到安全问题。所以需要 API网关作为外部系统访问的统一接口。

服务发现 与 服务路由 实际上都是在自动化范畴里的。（可以先不考虑）