可扩展 - 有生命力的软件系统，都是在不断迭代和发展的
拆，就是将原本大一统的系统拆分成多个规模小的部分，扩展时只修改其中一部分即可，无须整个系统到处都改，通过这种方式来减少改动范围，降低改动风险
怎么拆分？ 面向流程（展示层 → 业务层 → 数据层 → 存储层），面向服务（注册、登录、信息管理、安全设置等服务），面向功能（比如注册再分为手机号注册、身份证注册、学生邮箱注册三个功能）； 不同的拆分方式本质上决定了后续的扩展方式
- 面向流程拆分：分层架构。
- 面向服务拆分：SOA、微服务。
- 面向功能拆分：微内核架构。
分层架构：隔离关注点（separation of concerns），即每个层中的组件只会处理本层的逻辑，层层传递，整个业务流程是按照层进行依次传递的，不能在层之间进行跳跃； 代价是冗余，改个东西每层都要改，由于每个请求都要跨越多层，性能也会有影响
SOA：Service Oriented Architecture 面向服务的架构
SOA 架构是比较高层级的架构设计理念，一般情况下我们可以说某个企业采用了 SOA 的架构来构建 IT 系统，但不会说某个独立的系统采用了 SOA 架构
ESB 企业服务总线 ~ 需要实现与各种系统间的协议转换、数据转换、透明的动态路由等功能，转换是需要耗费大量计算性能的，当 ESB 承载的消息太多时，ESB 本身会成为整个系统的性能瓶颈
微服务拆分过细，过分强调“small”。微服务基础设施不健全，忽略了“automated”。微服务并不轻量级，规模大了后，“lightweight”不再适应。
拆分方法：根据业务逻辑拆分、根据可扩展性拆分、根据可靠性拆分、根据性能拆分
基础设施
1. 服务发现、服务路由、服务容错：这是最基本的微服务基础设施。
2. 接口框架、API 网关：主要是为了提升开发效率，接口框架是提升内部服务的开发效率，API 网关是为了提升与外部服务对接的效率。
3. 自动化部署、自动化测试、配置中心：主要是为了提升测试和运维效率。
4. 服务监控、服务跟踪、服务安全：主要是为了进一步提升运维效率。
自动化测试、自动化部署、配置中心、接口框架、api网关、服务发现、路由、容错、监控、追踪、安全
微内核架构，基本就是插件式的设计，插件管理、插件连接和插件通信，比如OSGi 当作一个微内核的架构模式
规则引擎
