开发者学堂课程【阿里巴巴分布式服务框架 Dubbo 快速入门：应用的架构演变】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/624/detail/9454
应用的架构演变
架构服务的发展演变
应用架构发展的路线图，解释了从单一的小型应用转变成一个分布式的大型应用
（1）单一应用架构：
当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。
缺点：
不易扩展
不易协同开发
不易对服务器进行维护
（2）垂直的应用架构:
将每一个应用独立分布到每一个小服务器上
分工合作容易互不干扰
用户拓展容易
拓展应用访问量增大时可以多增加几台服务器
缺点;
界面和逻辑不易分离
应用之间不可能完全独立，大量的应用之间需要交互之间需要交互。
当我们这个垂直应用越来越多，因间还想要交互，我们就可以把他们的核心业务单独抽取出来，比如分布式架构服务：
（3）分布式架构服务：
将之前的用户应用，抽取成了用户的界面，web 界面和用户业务逻辑。
这样做的好处是当业务逻辑不变的情况下，如果只想改界面，就只需把界面一改，界面的服务器可以重新启动一下，核心的业务逻辑还在其他的服务器上。
比如那么比如用户界面，要展示我们用户信息，包括还要查出一些订单，查出一些商品，那就去掉其他服务器的各个业务即可。
现在还有一个最大的问题，用户的 web 可能在 a 服务器上用户的业务，而订单放在 B 服务器上，如果 a 服务器要去来调 b 服务器的功能，如果垂直的应用架构是写在一个应用里面 a 直接调取 b 的方法，直接调用即可，这样的调取方式叫做进程内通讯，因为他们都在一个服务器上。如果现在发现 a 跟 b 已经分割异地在两处应用里，这两处代码之间如何互调？
把这个调用我们称为 CRPC，全称为远程过程调用。分布式服务的这个架构下，最核心的难点就是如何进行远程过程调用，以及如何拆分业务，提升我们业务的复用程度。那么此时，一个好的分布式服务框架，也是来帮我们来解决远程过程调用的框架能极大地简化在开发内等问题。
后来随着业务不断的增多，分拆的服务也越来越多，有成千上万的服务器再来处理各种不同的服务，此时出现的一些资源浪费情况就尤为严重，比如用户业务这一块儿，访问量比较小，却有100台服务器在处理，而商品业务的访问量比较大，只有10台服务器在处理，此时就应该有一个能基于访问压力的调度中心，能帮我们实时监控这些数据动态的调度，提高资源的利用率。
此时就可以采用流动计算架构，引入调度中心，它负责维护这些服务之间的复杂关系，以及实时管理整个服务集群。比如 a 服务器访问量加大，就多增加几台，实施动态调整。
假设第一台有100个请求，第二台有200个请求，第三台有10000个请求，那么下一次请求出现，就应该找比较闲的服务器来处理请求，以此来提高我们整个服务的利用率。
架构的变化必然也会引起很多技术的兴起，分布式架构下，也会有非常多的技术，我们将一点一点的去探索。
