高性能、高可用之后是可扩展。
可扩展架构的基本思想和模式
所有的可扩展性架构设计，背后的基本思想都可以总结为一个字：拆！
常见的拆分思路有如下三种。
面向流程拆分：将整个业务流程拆分为几个阶段，每个阶段作为一部分。学生信息管理系统的展示层 → 业务层 → 数据层 → 存储层
- 优点：扩展时大部分情况只需要修改某一层，少部分情况可能修改关联的两层，不会出现所有层都同时要修改。
- 分层架构
面向服务拆分：将系统提供的服务拆分，每个服务作为一部分。学生信息管理系统的注册、登录、信息管理、安全设置等服务
- 优点：对某个服务扩展，或者要增加新的服务时，只需要扩展相关服务即可，无须修改所有的服务。
- SOA、微服务
面向功能拆分：将系统提供的功能拆分，每个功能作为一部分。学生信息管理系统中注册服务的手机号注册、身份证注册、学生邮箱注册三个功能
- 优点：对某个功能扩展，或者要增加新的功能时，只需要扩展相关功能即可，无须修改所有的服务。
- 微内核架构
不同的拆分方式，本质上决定了系统的扩展方式。
感想：设计的所有系统必然会按照流程拆分，这是个必选项。在面向服务拆分和面向功能拆分上，全都是面向服务拆分。现在大部分都是用微服务的方式进行开发了。
传统的可扩展架构模式：分层架构和SOA
分层架构是很常见的架构模式，它也叫 N 层架构，通常情况下，N 至少是 2 层。例如，C/S 架构、B/S 架构。常见的是 3 层架构（例如，MVC、MVP 架构）、4 层架构，5 层架构的比较少见，一般是比较复杂的系统才会达到或者超过 5 层，比如操作系统内核架构。
分层架构设计最核心的一点就是需要保证各层之间的差异足够清晰，边界足够明显，让人看到架构图后就能看懂整个架构。
分层结构的代价就是冗余，也就是说，不管这个业务有多么简单，每层都必须要参与处理，甚至可能每层都写了一个简单的包装函数。分层架构的优势就体现在通过分层强制约束两两依赖，一旦自由选择绕过分层，时间一长，架构就会变得混乱。
SOA 的全称是 Service Oriented Architecture，中文翻译为“面向服务的架构”。
- 所有业务功能都是一项服务，服务可大可小，可简单也可复杂。
- ESB 的全称是 Enterprise Service Bus，中文翻译为“企业服务总线”。SOA 使用 ESB 来屏蔽异构系统对外提供各种不同的接口方式，以此来达到服务间高效的互联互通
- 松耦合的目的是减少各个服务间的依赖和互相影响。因为采用 SOA 架构后，各个服务是相互独立运行的，甚至都不清楚某个服务到底有多少对其他服务的依赖。
感想：刚开始工作的时候，使用PHP的Yaf框架进行开发，使用标准的MVC模式，前后端都在同一套代码上开发。后来慢慢都切到Go，走微服务了，前后端也完全进行了拆解。
深入理解微服务架构：银弹 or 焦油坑？
SOA 和微服务本质上是两种不同的架构设计理念，只是在“服务”这个点上有交集而已
微服务具体有哪些坑：
- 服务划分过细，服务间关系复杂
- 服务数量太多，团队效率急剧下降
- 调用链太长，性能下降
- 调用链太长，问题定位困难
- 没有自动化支撑，无法快速交付
- 没有服务治理，微服务数量多了后管理混乱
微服务拆分过细，过分强调“small”。
微服务基础设施不健全，忽略了“automated”。
微服务并不轻量级，规模大了后，“lightweight”不再适应。
感想：SOA没用过，工作的公司大多偏互联网，所以没有适合SOA的场景。微服务相对了解的多一些，以前写过微服务之服务框架和注册中心，微服务不单单指一个Server，其实是一套完整的体系。当初服务发现这套东西是运维同事推的，我们是公司第一家用的，用了没多久推这块功能的人换了工作，中间还出过一些事故，如发现不到服务了、服务发现不稳定，后续慢慢就稳定下来了。微服务还是蛮值得推进的。如果团队职能很大，比较重要的是控制好微服务的数量，以前合作过一个团队，创建新的微服务需要+2评审，也是因为吃过亏了。
微服务架构最佳实践 - 方法篇
服务粒度：于微服务设计和开发阶段，即一个微服务三个人负责开发。
- 首先，从系统规模来讲，3 个人负责开发一个系统，系统的复杂度刚好达到每个人都能全面理解整个系统，又能够进行分工的粒度；
- 其次，从团队管理来说，3 个人可以形成一个稳定的备份，即使 1 个人休假或者调配到其他系统，剩余 2 个人还可以支撑；
- 最后，从技术提升的角度来讲，3 个人的技术小组既能够形成有效的讨论，又能够快速达成一致意见；
拆分方法：
- 基于业务逻辑拆分：将系统中的业务模块按照职责范围识别出来，每个单独的业务模块拆分为一个独立的服务。
- 基于可扩展拆分：将系统中的业务模块按照稳定性排序，将已经成熟和改动不大的服务拆分为稳定服务，将经常变化和迭代的服务拆分为变动服务。稳定的服务粒度可以粗一些。
- 基于可靠性拆分：将系统中的业务模块按照优先级排序，将可靠性要求高的核心服务和可靠性要求低的非核心服务拆分开来，然后重点保证核心服务的高可用。
- 避免非核心服务故障影响核心服务
- 核心服务高可用方案可以更简单
- 能够降低高可用成本
- 基于性能拆分：将性能要求高或者性能压力大的模块拆分出来，避免性能压力大的服务影响其他服务。
感想：一般按照业务逻辑拆分好一点，因为很多时候团队和业务是对应的。至于要不要再按照扩展性、可靠性、性能区分，看自己的需求。
微服务架构最佳实践 - 基础设施篇
1.自动化测试涵盖的范围包括代码级的单元测试、单个系统级的集成测试、系统间的接口测试，理想情况是每类测试都自动化。
2.自动化部署系统包括版本管理、资源管理（例如，机器管理、虚拟机管理）、部署操作、回退操作等功能。
3.配置中心包括配置版本管理（例如，同样的微服务，有 10 个节点是给移动用户服务的，有20 个节点给联通用户服务的，配置项都一样，配置值不一样）、增删改查配置、节点管理、配置同步、配置推送等功能。
4.接口框架不是一个可运行的系统，一般以库或者包的形式提供给所有微服务调用。例如，针对上面的 JSON 样例，可以由某个基础技术团队提供多种不同语言的解析包（Java 包、Python 包、C 库等）。
5.API 网关是外部系统访问的接口，所有的外部系统接⼊系统都需要通过 API 网关，主要包括接入鉴权（是否允许接入）、权限控制（可以访问哪些功能）、传输加密、请求路由、流量控制等功能。
6.服务发现
- 自理式结构就是指每个微服务自己完成服务发现。
- 代理式结构就是指微服务之间有一个负载均衡系统（图中的 LOAD BALANCER 节点），由负载均衡系统来完成微服务之间的服务发现。
7.服务路由：从所有符合条件的可用微服务节点中挑选出一个具体的节点发起请求。常见的路由算法有：随机路由、轮询路由、最小压力路由、最小连接数路由等。
8.服务容错包括请求重试、流控和服务隔离。通常情况下，服务容错会集成在服务发现和服务路由系统中。
9.服务监控需要搜集并分析大量的数据，因此建议做成独立的系统，而不要集成到服务发现、API 网关等系统中。
10.服务跟踪会记录其中某次请求的发起时间、响应时间、响应错误码、请求参数、返回的 JSON 对象等信息
11.服务安全主要分为三部分：接入安全、数据安全、传输安全。通常情况下，服务安全可以集成到配置中心系统中进行实现，即配置中心配置微服务的接入安全策略和数据安全策略，微服务节点从配置中心获取这些配置信息，然后在处理具体的微服务调用请求时根据安全策略进行处理。
感想：同上
微内核架构详解
微内核架构（Microkernel Architecture），也被称为插件化架构（Plug-in Architecture），是一种面向功能进行拆分的可扩展性架构，通常用于实现基于产品（原文为 product-based，指存在多个版本、需要下载安装才能使用，与 web-based 相对应）的应用。例如 Eclipse 这类 IDE 软件、UNIX 这类操作系统、淘宝 App 这类客户端软件等。
微内核架构包含两类组件：核心系统（core system）和插件模块（plug-in modules）。核心系统负责和具体业务功能无关的通用功能，例如模块加载、模块间通信等；插件模块负责实现具体的业务逻辑，例如专栏前面经常提到的“学生信息管理”系统中的“手机号注册”功能。
微内核的架构本质就是将变化部分封装在插件里面，从而达到快速灵活扩展的目的，而又不影响整体系统的稳定。
微内核的核心系统设计的关键技术有：插件管理、插件连接和插件通信。
规则引擎从结构上来看也属于微内核架构的一种具体实现，其中执行引擎可以看作是微内核，执行引擎解析配置好的业务流，执行其中的条件和规则，通过这种方式来支持业务的灵活多变。规则引擎：一个简单的easyRule的demo
感想：微内核框架完全没有用过，但看了一下例子，感觉还是很有用处的，很多业务需求里会有类似于多个规则判断处理的问题，正好可以用这个方案解决。