基本思想: 拆
CAP原则 ：又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾
面向流程拆分，面向服务拆分，面向功能拆分
面向流程拆分：分层架构
展示层: 负责页面设计
业务层: 负责业务逻辑
数据层: 负责数据访问
存储层: 负责数据存储
面向服务拆分: 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网关作为外部系统访问的统一接口。
服务发现 与 服务路由 实际上都是在自动化范畴里的。（可以先不考虑）