分布式架构演进和架构三要素（1）
罗马不是一日建成的，软件架构也一样。技术是为了业务服务的，如何适应当前以及中长期的业务需求，保持演进是架构设计的一个重要的原则。回顾大型的互联网公司的技术架构的发展，基本都符合这样的路径：首先是简单有效的架构设计快速验证商业模式，支撑当前的商业目标；然后随着业务的快速发展，对技术提出新的要求，大容量，高性能，高并发，高可用等等，架构不断演进以适应其发展。我们大体看下以下的演进方式：
1. 单台应用服务器：用户请求通过单台服务器响应，服务相关的计算，存储由一台服务器处理完成。使用单台服务器实现简单，缺点是做垂直扩展，通过增强服务器的处理能力来提升系统的服务吞吐量，包括提高CPU，内存，硬盘等的能力，随着性能越来越高，成本也会急剧增加。单台服务器无备份，当服务器故障时，服务也会受到影响。
2. 应用和数据分离：不用的服务和计算对服务器的资源要求往往不同，将业务的计算逻辑由应用服务器处理，而数据存储交由专门的数据存储服务器完成。这也是我们讲的系统行为和数据的分离。数据是系统的核心，应用和数据分离也是做服务拆解，实现高可用可伸缩性等的初始步骤。
3. 服务器集群：随着业务数据量越来越大，必须使用多台服务器来处理请求，即将服务的处理分布在不同的应用服务器，通过负载均衡器来分配和调度服务请求。将数据库部署在不同的数据库服务器，文件服务部署在不同的文件服务器，缓存部署在不同的缓存服务器。
4. 数据库读写分离：业务中的读操作要远超过写操作，读操作通过缓存机制等能够做到高性能，但写操作往往比较慢。通过主从数据库，将数据库的读写操作分离能极大提升系统性能。可以是一主一从或一主多从。主数据库服务器负责读写操作，从服务器只负责读操作。通过复制将数据从主数据库同步到从数据库，每台数据库服务器都存储了所有的业务数据。
5. 业务拆分：随着业务本身越来越复杂，业务分配设计带来产生的收益会逐步降低，需要对业务本身进行拆分，拆解成颗粒度更小的服务。通过拆解服务，简单的服务更容易做到高性能，且可针对单个服务进行扩展，消除瓶颈业务服务。
6. 微服务化：当业务服务越来越多时，需要对服务进行治理，易于扩展和发布。
日志系统：主要用于收集和管理为服务产生的日志。
监控系统：用于实时监控微服务运行情况，例如CPU，内存，QPS等。
配置中心：用于统一管理微服务的配置。
网关：用于给前端调用提供统一的入口。
注册中心：用于管理微服务相关的配置信息，如服务提供者，常用的有ZooKeeper等。
消息中心：主要用于微服务之间的解耦，常用的技术有Kafka，RabbitMQ等。
架构三元素
高性能：系统如何提高请求的响应时间和减少延迟。
高可用：软件对服务请求的可操作性和可见程度。高可用主要通过冗余来实现。
可扩展：系统要易于扩展，快速响应新的需求。