你是否了解这些常用架构？ _架构

文章插图
我们日常生活中使用很多应用程序，有微信、抖音、王者这种涉及多人联网互动的大型应用，它们以操作系统作为宿主；也有网站、小程序、PWA等借壳的应用。面向用户表现为Android/IOS/windows/macOS/浏览器/H5/Terminal 等端上的应用程序，名为 Client 。更多情况下，业务的核心逻辑体现在背后看不见的服务，名为 Server 。
从普通用户视角跳出来，切换到程序员视角，应用程序可以理解为是M个Client和N个Server的组合。在软件开发过程中，Client/Server的边界如何划分，Server之间如何通信，多个Server如何组织能够保证整个系统按照预期的方式运行，都是服务架构要考虑的问题。
下面我们简单串一下主流的几个服务架构，包括分层架构、client-queue-worker架构、微服务架构、事件驱动架构、大数据、大计算架构，并从四个方面对每个架构进行总结：

架构的描述和架构图
推荐的使用场景
优点、潜在问题和最佳实践
一些现实场景中的示例

分层架构

文章插图
WAF全称Web Application Firewall，就是防火墙
在开发传统企业应用中，分层架构得到了广泛使用。一个应用被划分为多个逻辑功能的层，比如展示层、业务逻辑层和数据访问层。这些分层同时也定义了依赖关系，每个层都只能调用它下面的层。每个层可以是一个独立的模块，整个系统的各个模块可以独立甚至并行开发和测试，交付质量可以得到比较好地保证，所以这是目前最为广泛使用的架构之一。但它也有一些难以解决的问题，尤其体现在产品上线后的变更上。体现在：

在大型系统中，层的划分逻辑并不那么明显，可能出现过度分层的问题
分层往往是从技术角度做的，没有按照业务领域进行，导致系统对业务扩展不友好
分层以后，跨层通信比较困难，对性能敏感的业务无法接受由此带来的网络通信开销和编解码开销
迭代困难，因为需要所有层的变更，协调多个团队的成本非常高

分层架构在私有云系统中非常常见，比如一个私有云的解决方案可以设计为：

物理机层：物理机、网络设备等
虚拟化层：将物理资源进行虚拟化，可以用kvm
资源管理层：对资源进行调度编排，也提供故障恢复、弹性扩容等功能，比如k8s
服务编排层：定义和管理服务的部署、配置和自动化，通常是k8s上做二次开发出的一层壳
用户展示层：通常是web界面、命令行，也可以是API

任务调度架构 Web-Queue-Worker

文章插图
这个架构下，用户通过前端Web页面将任务异步发送到后端，协议可以是HTTP或RPC 。通常情况下，后端的worker接收任务后，执行一段事件CPU密集型计算，生成结果。
作为对比，分层架构中来自client的请求大都同步到达，请求可以很快得到满足，server端处理完成后同步返回；相反，任务调度架构下，每个请求要得到满足，可能耗费server大量的计算/网络或存储资源，所以异步返回。
在通信方式上，任务调度架构更多地采用类似于队列的方式（不一定真的有一个消息队列，从数据库拉取任务也算）
微服务架构

文章插图
如果应用非常复杂，可以采用微服务模式。微服务应用是由很多小且独立的服务组合而成，每个服务都独立实现一套完整的业务能力。服务的关系非常松散，仅通过API进行通信。
每个服务都可以由一个独立的研发团队进行开发，理论上也可以单独部署，不用和其他团队进行太多的协同。因此，微服务架构非常鼓励频繁的更新。一个微服务架构可以非常复杂，它可以由多个分层架构应用和任务调度架构应用组合而成。
由于服务非常多，DevOps的重要性就凸显出来了。如果操作正确的话，这种架构可支持高度灵活的发布节奏、更快的创新和高度的弹性及扩展性。