我们首先来看一下高并发、高性能、高可用，也就是我们经常提到的三高系统。当我们流量非常大的情况下，我们一定要保证这三高。这其中高并发是指要支持很多并发用户，高性能是在高并发的前提下保证优秀的性能，高可用则是保证系统在某一节点出现问题时不会整体宕机且继续持续提供服务。由此可见三高的主要特性则是分布式和集群化，而我们主要要解决的问题则是安全性。
上图是一些常见的与我们生活息息相关的高并发场景。左上电商秒杀是最常见的场景了，去年疫情期间口罩紧缺抢口罩就是这个场景，很多人在一个统一的时间去点击同一个页面，这个的并发数是特别高的。右上则是抢票，这个大家也很熟悉了，特别是春节需要回家的在外地工作的朋友们，肯定都是开个抢票软件一直刷给自己抢票的，这种的并发流量特别大。左下则是银行交易系统，我们所有的线上、线下扫码其实都需要通过银行系统，这就让它的日交易量极大。最后是 Authing 身份证，我们主要是给用户做整套的身份认证和用户管理体系，这个体系让开发者避免了重复构建身份的操作，减少了开发者编写的代码，提高他们的效率。以下图作为例子：
图中展示的是我们的核心组件，表面上看是一个简单的登录框，也就是用户认证界面，但是其背后有一个庞大的由用户体系、管理体系、认证体系等一系列服务组成的后台支撑。尽管用户只是进行了用户名和密码的输入，但是我们要考虑到的不仅仅是用户的安全认证、多种登录方式，还有很多用户同时认证时要如何处理等等多种事项。除此之外，我们还需要考虑到如何让包括私有化用户在内的多种类型的客户实现高可用和快速部署，完成快速集成。
如果有做高并发的朋友，对于 CAP 理论一定不陌生。它的主要观点是分布式系统无法同时满足三个，只能够满足其中两个。即分布式系统要么满足 CA，要么满足 CP，但无法同时满足CAP。其中的意思是说如果满足了可用性和分区的容错性，那可能意味着要牺牲一致性，进而达到最终的数据一致性。它是告诉我们要作出取舍。
从单体应用架构说起
上图中示意的单体应用构架是早期常用的模式。早期因为人手紧缺通常会将 Web 和 Server 一起开发再一起部署，之后和数据库连在一起就可以正常提供服务。这么做的优点是维护简单，但是迭代比较麻烦。
现在前后端分离后，我们通常把 Web 和 Server 分开为两个服务部署，为快速迭代提供了便利。如果我们有一个 Server 需要修复，我们可以单独对这个服务进行代码修改和部署，然后快速上线服务。但是它的缺点是随着业务的增多，Server 包含的内容也越来越多，这会让它耦合很深进而导致服务变慢。这一点我深有体会，多年前我有个朋友架构出了问题，有段时间每到周末他会买一袋瓜子来我家一起琢磨。为什么要买一袋瓜子呢？因为耦合的太深了，服务启动要 5 分钟，改一个东西又要等 5 分钟重启，所以我们嗑着瓜子聊天等待。
类似上面提到的依赖复杂、臃肿繁杂是单体应用会遇到的一个问题，除此之外单体应用还有以下问题：
- 单点瓶颈
- 稳定差
- 扩展性差
- 业务模型缺失
- 新业务扩展差
- 业务流程基础能力缺乏
- 前后端耦合严重
- API 杂乱难维护
既然痛点如此明显，那么如何去优化就很重要。
