这是我参与「第五届青训营」伴学笔记创作活动的第 7 天
lecture7 架构初探
-
认识架构
单机
单体、垂直应用 | 垂直切分
按照这个思路：
我们把进程部署在多个机器上，并引入负载均衡层，经过这样的垂直切分，就来到了单体架构。多个机器就好比把蛋糕切成几大块，负载均衡层负责引导用户去事先切好的几块蛋糕处
在单体架构基础上，进一步地，再把不同应用的代码从之前一个大的进程中拆分出来，就来到了垂直应用架构。按应用拆分进程，就好比慕斯、戚风等蛋糕在不同的点发配
这种经过垂直切分的架构，尝试解决了单机服务的水平扩容、运维停服问题。当然这里面很多细节还没有提及，比如，多个机器上部署的进程如何保证数据一致性。这些我们后面会一并讨论
虽然它们解决了单机服务的两个最重要的问题，但也面临着很多挑战。这其中，有两个问题使得我们不得不放弃单体和垂直应用架构：
随着业务场景越来越复杂，服务的职责也越来越多。学过面向对象程序设计的同学都知道单一职责的重要性，在软件架构里也是一样的。开发者不仅要关心 Web 后端业务逻辑，还要关心缓存、持久化存储，甚至跟机器打交道。长此以往，RD 很难分出精力专注于业务能力的开发
业务发展需要上线、变更，将会影响所有其他不涉及的场景。一旦出问题，影响面不可估量
既然可以根据应用把架构做垂直拆分，那是否可以根据模块/职责对架构进行水平拆分呢？
SOA、微服务 | 水平切分
按照这个思路，我们把原本包含了众多复杂逻辑的进程按照功能单元抽象成多个服务，以服务为一等公民，并为它们之间的通信定义标准，便得到了 SOA 架构。
这里有两个相对比较重要的概念：
服务，是根据功能抽象出来的概念。比如说，处理用户登录信息的 Passport 服务，负责持久化存储的数据库服务，以及为了加快查询速度的缓存服务等
通信标准，是服务之间通信的基石。没有实现定义好的通信标准，就好比多个做蛋糕的师傅语言不通，难以协作
为了服务之间更好的通信，有两个大的发展方向：中心化和去中心化。因为中心化的方案形态较重，拓展性不佳，普及性不佳，我们跳过不讲，感兴趣的同学可以自己了解一下。而去中心化的方向，最终的形态就是微服务架构
这下，
-
不同模块的 RD 可以专心于自己的业务逻辑了，开发迭代效率得到显著提高
-
各个服务独立运维，变更操作的影响面可控，应用整体的稳定性得到了提高
最后，我们还需要回答垂直切分和水平切分所产生的一系列问题：
由单机部署演进来的分布式架构，如何解决数据一致性
服务越来越多，依赖越来越复杂，如何做到高可用
一个团队甚至一个人可能同时管理多个微服务，如何运维
微服务的目标是强化单一职责，控制爆炸半径，如何在解耦和『过微』之间取舍
-
企业级后端架构分析
云计算
云原生
聊完云计算，有必要马上来看一下云原生。云原生，实际是云原生（计算）的简称，它是元计算发展到现在的一种形态。
- 云原生技术为组织（公司）在公有云、自由云、混合云等新型的动态环境中，构建和运行可弹性拓展的应用提供了可能。它的代表技术有：
- 容器化
- 服务网格
- 微服务
- 不可变基础架构
- 声明式 API
基于这些技术，开发者可以构建出容错性好、易于管理、具备较好观测性的云服务。结合可靠的自动化机制，服务可以轻松应对频繁和可预测的重大变更。
云原生主要涉及四个大方面：
弹性资源：基于虚拟化容器以及灵活的编排调度机制，可以为云服务提供快速扩缩容能力，而且极大程度地提高了物理资源的利用率。在这方面，kubernetes 技术已经称为了业界的标准
微服务架构：还记得前面我们聊到的微服务架构么？没错，它也是云原生的重要基石之一。依托于功能单元解构，使得云服务具备了快速迭代的可能，业务得以迅速发展；统一的通信标准能够帮助越来越多的组件加入到云原生的大家庭，同时也使得各组件之间的交互变的更容易
DevOps：设计->开发->测试->交付->开发->测试->交付，自动化的流程使得软件的工作流程更高效，将微服务架构的优势发挥的淋漓尽致
服务网格：如果说微服务架构的重要进步，是将庞大的单体服务按照业务功能解耦开来，那么，服务网格的重要进步就是将业务逻辑与网络通信和治理解耦开来。业务不再需要关心异构系统中 RPC 中间件治理能力的不统一，也使得复杂的治理能力的落地成为可能
-
弹性计算资源
-
弹性存储资源
-
DevOps
-
微服务架构
- HTTP
- RPC
-
服务网格
- 蛋糕店
-
企业级后端架构的挑战
-
后端架构实战
解决在线分析引擎的数据一致性问题：一致性哈希
解决时序数据库压力：将其作为旁路工具，采用纯内存的在线分析引擎进行实时策略计算
离线分析：使用消息队列解耦、削峰
离线回馈在线
