从课程中，我们学到了架构的定义、由来、发展与现状；认识了现如今主流的云原生、微服务架构的原理和特征；以字节跳动在后端架构实战的实践深入地观察了后端架构可能存在的缺陷及对应的解决方案。
现在，我以课后作业为载体，以设计蛋糕房线上业务架构的方式巩固所学、以学促练。
单体架构
首先，我们有一个最基本的单体架构。如图：
很显然，这个架构存在着很多问题：没有对特定客户端的区分、I/O协议明文且过于简单、没有负载均衡、阻塞式......
我们从架构的发展历史开始逐步地优化我们的架构。
垂直应用架构
首先，我们可以采用多线程的方式尽可能的利用单体服务器得到性能，同时使用一个路由分发客户端请求。
但这样仅仅是将业务简单粗暴地分成了多个等分，虽然提升了性能，但是随着之而来的高耦合、一致性问题便变得不可忽视。
因此我们可以对业务进行分析，进行垂直的、贯穿一个请求的拆分。
这下，由于对业务的垂直拆分，大大减小了不同业务间的影响，降低了耦合，提高了内聚。
然而，问题依然存在：除了客户端的区分外，这些业务都是运行在同一台设备上的，共享IO使得对数据的操作变得十分低效；业务的垂直拆分并没有做到将一个请求继续拆分成更小的流程，这使得对于异常的排查变得困难......
以上问题中，单机带来的性能问题尤为突出。因此，我们引入分布式以着重解决这个问题。
分布式架构
分布式的思路其实十分简单：一台机器不能满足要求那就上多台机器。
上图就是应用分布式之后的蛋糕店架构。可以发现这与垂直应用架构仅仅有两处不同：
- 由于业务分布在不同的机器上，因此原先哪个进程空下来就把请求发到哪里的策略就显然行不通了。这时我们引入负载均衡服务器，通过不断地对下游服务器状态的采集与分析，将请求尽可能的发送到合适的机器上。
- 每个业务运行在集群而不是原先的线程上，这会带来更高的性能，更大的IO吞吐。
然而架构的复杂化一定会带来工程的复杂化。一致性、负载均衡变得尤为重要。一次业务流程的异常带来的连锁反应也就会触发更大的雪崩。
因此，我们开始思考，如何将一个业务，一个请求拆分成更小的、一段一段的流程，这样一来，既可以不用阻塞在一些业务中的耗时环节；同时错误带来的爆炸半径变小，错误的定位也就变得更加简单。
SOA/微服务
很多人将微服务视为SOA的一个变种，但在本文中不讨论两者的区别，而是将双方认为架构发展历史中的同一个阶段。我们将业务拆分成如图的小的流程。
随着服务被拆分成微服务，微服务间的调用关系变得十分的复杂且频繁，同时又因为微服务往往不在同一架设备上，网络的开销也是无法忽视的。因此人们采取了许多的方式来解决这个问题，其中RPC便是当今主流的方案之一。通过自定义的、面向字节的协议，我们可以省下HTTP的极大损耗，同时在灵活性上也有了极大提升，这样，便能将原先较难考虑的客户端问题通过附加参数的方式予以解决。微服务本身的启动开销又很小，在集群的控制下甚至可以忽略不计，这就使得通过云原生技术进行动态的性能调整变为了可能。
然而，IT是一个日新月异的行业，解决了旧的问题，新的问题便会凸显出来。我们必须通过不断的调研，不满足于现有技术，而是发现问题解决问题，才能创造出价值。
