架构，从大的来说，就是由多个结构和关系组成，形象的来看可以是多个服务组成。服务就涉及到服务本身以及服务与服务之间交互。
服务本身怎么更快的搭建，更快的完成业务功能，就需要了解Spring 和 ORM 等各类框架，框架本身就是帮我们将各类交互封装起来，提供标准统一的注解，或者其他实现方法，让我们更加关注业务逻辑，而不用去太多关注非业务细节，可以说是提供一种便捷的能力。同时，业务要持久化，就需要存储到硬盘，MySQL此类数据库也可以理解成对底层细节的抽象，同时提供事务能力，让我们能更快捷的将业务完成抽象。有了工具，做完了业务抽象，实现了功能，也只是写完了代码，怎么能让代码在多个服务器部署起来，如何屏蔽不同操作系统的差异。这就是JVM干的事情，让我们可以做到一次编译，到处运行。就是因为JVM充当了代码和操作系统之前的一层抽象，帮我们屏蔽了这层差异。部署完成，就需要有浏览器、或者其他客户端来访问，访问就需要走网络，就涉及到网络通信，就涉及到阻塞IO、非阻塞IO、信号驱动IO、多路服务IO、异步IO等各类IO模型，阻塞IO简单但是要等待IO的结果，效率也就最低。异步IO实现复杂，但是实现之后效率又是最高的。也就出现了NIO的Netty框架帮我们来封装。
当越来越多的请求到达我们服务，如何让服务支持更多的请求，这里涉及到一个C10K到C100K的问题。为了让服务支持更多的请求，一种就是垂直扩展，一种就是水平扩展。先说垂直扩展，就是不断提高单个服务的处理能力，比如并发编程，开启线程池等，比如增加缓存，减少对数据库的访问，因为缓存往往在本地内存(Guava Cache)或者其他服务器的内存(Redis)中，比访问数据库更高效。再说，水平扩展，就是提供无状态的服务，让多个服务均衡的为这些请求提供处理能力。同时，还可以让服务拆分的更细，每个服务只提供某类业务能力，比如用户能力、订单能力、优惠能力拆分开，分别维护，这就是所谓的微服务。那按照业务拆分之后，就会涉及到服务与服务之间的交互，也就出现了RPC通信，既然HTTP也能提供通信能力，为何还要RPC呢？因为适用的场景不同，HTTP是为了满足超文本传输而有的协议，它的协议头也就比较重。RPC是为了服务之间的通信，可以通过自定义协议头、选择合适的序列化、合适的IO方式来更好的满足当前的需求。这里就体现了技术都有自己的使用场景，没有绝对好的技术，都是在当前业务场景的讨论，找到更适合的技术。当然，服务与服务之间的通信，还可以通过MQ等这类消息队列，来达到削峰、异步、解耦的效果。那么有了优势，也就需要考虑消息丢失、消息重试、消息幂等等这些问题的解决方案。
最后，当我们业务服务本身通过拆分可以扛住大流量之后，还需要考虑存储层的抗压。怎么解决存储层的抗压呢？同样的思路，一种是垂直扩展，一种是水平扩展。本质都是为了解决一个表不要存储太大的问题，垂直扩展就是将表按照业务进行拆分不同的库。水平扩展就是按照时间、或者分片存储到多个表中。这样就可以缓解单个数据库，单个数据表的压力。一种就是基于现有的MySQL，结合分库分表中间件来实现。一种就是采用现有的分布式存储方案，比如TiDB、Elasticsearch、Hadoop套件的HDFS等。