目前国内盛行分布式与微服务结构设计，大小公司、电商、物联网等行业都是紧随这些概念在开展项目开发和运营，据我日前和一些架构师朋友讨论过程中发现不但大多公司没有把整体的方案落地，有些架构师甚至都不知道为什么采用这一系列的服务就开始了开发工作，这对软件行业来说是非常危险的。
谈起来大型平台架构都是采用什么技术、什么框架、什么协议等等开头，我认为大可以不必先着急去谈论技术，我们不妨来倒推一下架构思维，先来谈论一下大型平台的核心要素，弄明白架构设计到底是根据什么样的需求来进行设计的，它有什么样的标准和特性。
首先，给大家讲解下大型平台的核心要素主要体现在哪几个方面：
1性能：不管是什么产品，性能永远是客户要求的第一感官，点个查询要等10秒，跳转个页面总是加载不到信息，架构设计再强大也无法让用户感知到你的努力，所以性能是产品第一个也是最重要的核心要素。
2可用性：如个人的信誉一般，大型平台的可用性就是它的信誉，哪怕一分一秒的宕机也不可能被原谅，这是一个不用讨论的硬指标，几乎所有的大型网站都承诺7*24小时可用。
3伸缩性：大型平台总是要跟随人们的节奏在运行，就像中国人过春节一样，平台也会有高峰和低谷，这时候就是考验一个平台的伸缩性的时候，可以添加多少服务器到集群中，添加后是否能无差别的提供服务是重要的扩展指标。
4可扩展性：这是几个核心要素中唯一一个关注功能性的指标，扩展性是说一个完整的平台上线后面对新的业务发展和需求变更，是否可实现对现有产品透明无影响，不改动或很少的改动现有功能就可以上线新产品。
5安全性：没有安全性，其它的都是笑谈，针对不同的行业对安全级别要求也不同，咱们在这里暂时提一下。
前面讲了，我们需要讨论一下这几个核心要素，确定一下这几个要素中间我们需要实现哪一些，具体的指标是什么，再根据不同的指标要求来采取对应的技术方案就会非常明确了。
为了方便大家能更好的理解架构思维，那我以10张架构设计图为大家阐述下阿里公司架构设计的主要发展历程。
一、最开始的网站架构
最初的架构，应用程序、数据库、文件都部署在一台服务器上，如图：
LAMP Linux+Apache+PHP+Mysql，经典配置。太多经典案例都是这样的架构设计，好处就是便易、方便、开发上线速度快、成本低。
二、应用、数据、文件分离
随着业务的扩展，一台服务器已经不能满足性能需求，故将应用程序、数据库、文件各自部署在独立的服务器上，并且根据服务器的用途配置不同的硬件，达到最佳的性能效果。
三、利用缓存改善网站性能
在硬件优化性能的同时，同时也要通过软件进行性能优化，在大部分的网站系统中，都会利用缓存技术改善系统的性能，使用缓存主要源于热点数据的存在，大部分网站访问都遵循28原则（即80%的访问请求，最终落在20%的数据上），所以我们可以对热点数据进行缓存，减少这些数据的访问路径，提高用户体验。
缓存实现常见的方式是本地缓存、分布式缓存。当然还有CDN、反向代理等。本地缓存，顾名思义是将数据缓存在应用服务器本地，可以存在内存中，也可以存在文件，OSCache就是常用的本地缓存组件。本地缓存的特点是速度快，但因为本地空间有限所以缓存数据量也有限。分布式缓存的特点是，可以缓存海量的数据，并且扩展非常容易，在门户类网站中常常被使用，速度按理没有本地缓存快，常用的分布式缓存是Memcached、Redis。
四、使用集群改善应用服务器性能
应用服务器作为网站的入口，会承担大量的请求，我们往往通过应用服务器集群来分担请求数。应用服务器前面部署负载均衡服务器调度用户请求，根据分发策略将请求分发到多个应用服务器节点。
常用的负载均衡技术硬件的有F5，价格比较贵，软件的有LVS、Nginx、HAProxy。LVS是四层负载均衡，根据目标地址和端口选择内部服务器，Nginx是七层负载均衡和HAProxy支持四层、七层负载均衡。如何选择根据各自的需求和特点，我们通常根据报文内容选择内部服务器，因此LVS分发路径优于Nginx和HAProxy，性能要高些。而Nginx和HAProxy则更具配置性，如可以用来做动静分离效果更佳（根据请求报文特征，选择静态资源服务器还是应用服务器）。
五、数据库读写分离和分库分表
随着用户量的增加，很快数据库就会成为最大的瓶颈，改善数据库性能常用的手段是进行读写分离以及分表，读写分离顾名思义就是将数据库分为读库和写库，通过主备功能实现数据同步。分库分表则分为水平切分和垂直切分，水平切换则是对一个数据库特大的表进行拆分，例如用户表。垂直切分则是根据业务不同来切换，如用户业务、商品业务相关的表放在不同的数据库中。
六、使用CDN和反向代理提高网站性能
假如我们的服务器都部署在成都的机房，对于四川的用户来说访问是较快的，而对于北京的用户访问是较慢的，这是由于四川和北京分别属于电信和联通的不同发达地区，北京用户访问需要通过互联路由器经过较长的路径才能访问到成都的服务器，返回路径也一样，所以数据传输时间比较长。对于这种情况，常常使用CDN解决，CDN将数据内容缓存到运营商的机房，用户访问时先从最近的运营商获取数据，这样大大减少了网络访问的路径。
而反向代理，则是部署在网站的机房，当用户请求达到时首先访问反向代理服务器，反向代理服务器将缓存的数据返回给用户，如果没有没有缓存数据才会继续走应用服务器获取，也减少了获取数据的成本。反向代理有Squid，Nginx。
七、使用分布式文件系统
用户一天天增加，业务量越来越大，产生的文件越来越多，单台的文件服务器已经不能满足需求。需要分布式的文件系统支撑。常用的分布式文件系统有很多，例如FastDFS、NFS。
八、使用NoSql和搜索引擎
对于系统产生的海量数据的查询，我们使用nosql数据库加上搜索引擎可以达到更好的性能。并不是所有的数据都要放在关系型数据中。常用的NOSQL有mongodb和redis，搜索引擎有lucene、Sorl、ElasticSearch。
九、将应用服务器进行业务拆分
随着业务进一步扩展，应用程序变得非常臃肿，这时我们需要将应用程序进行业务拆分，如百度分为用户、商品、订单、图片等业务。每个业务应用负责相对独立的业务运作。业务之间通过消息进行通信或者同享数据库来实现。
十、搭建分布式服务
如果以上的架构优化都不能承载系统的访问时，就要考虑分布式服务或微服务处理框架了。这时架构师会发现各个业务应用都会使用到一些基本的业务服务，例如用户服务、订单服务、支付服务、安全服务，这些服务是支撑各业务应用的基本要素。我们将这些服务抽取出来利用分部式服务框架搭建分布式服务。淘宝的SOA体系中Dubbo架构或SpringCloud微服务框架都是不错的选择。
小结：
以上10张图是ALI的架构演变史，非常简明的围绕最初我们定义的5个大型系统架构中的核心要素开展的系统升级。同时也再次印证了那句在架构图中经久不衰的台词“不要试图去设计一个大型系统架构”，因为现有的大型平台架构都是一步步经过众多的架构师的努力而演变而来的。试图一口吃个胖子的架构是不可想象的，不要为了技术而技术，不要为了潮流而技术，适合你现在的业务需要的架构才是最好的架构。
