大型网站都是从小型网站发展而来，架构也是一样。任何一个大型网站的架构都不是从一开始都是一层不变的，而是随着用户量和数据量的不断增加不断演进的结果。比如腾讯最初是靠ICQ起家，而阿里最初则是使用LAMP架构模式。了解大型网站的架构变迁更有助于我们了解微服务的由来。这里简单的介绍下架构的一般变迁过程，大型网站的架构演化要复杂的多，考虑的问题也更多。
单一应用架构
在网站建立之初，可能并没有特别多的用户，我们仅仅用一个服务器就可以满足需求了，这个时候我们将所有业务打成一个war包，与数据库一起部署在一台机器上。如下图为最初时期的单一应用架构：
应用于数据分离
随着用户的增多，业务量的增大，一台服务器用于同时处理应用服务、数据库和文件服务可能有些力不从心，这个时候可以先考虑将应用服务将数据服务分离，以便于每台服务器专用于自己的业务处理，这时候可以如下架构部署：
集群部署
一旦用户量以及流量开始增加，服务器的性能就会遇到瓶颈，这个时候必须要对系统架构做调整以及优化。而在这个阶段主要需要解决的问题是提升业务系统的并行处理能力，降低单机系统负载，以便支撑更多的用户访问操作。集群就是一种很好的方式，通过增加新的服务器来分散并发访问流量，只要业务系统能够随意支持服务器的横向扩容，从而实现可伸缩性和高可用性架构。
虽然通过集群可以提升并行处理能力以及对于高可用的实现，但是同时还需要考虑到业务的复杂度，如果仍然把所有的业务逻辑全部耦合在一起放在一个 war 包中来管理，那对于代码的维护和扩展来说是非常困难的。而且如果某个业务功能出现故障，会导致整个系统不可用。可以对业务进行垂直化拆分，简单来说，就是可以按照系统的业务功能拆分出多个业务模块，比如电上网站，会拆分出：首页、用户、搜索、订单、支付、商品等子系统。每个业务模块有可以有单独的文件服务器数据库服务器，以及集群部署.。
面向服务架构
随着对业务系统进行垂直化改造之后，以业务功能纬度拆分出来多个子系统，而在各个子系统中，会存在比较多的共享业务，比如用户信息查询，在支付业务中会涉及到、在首页中也会涉及到。那么势必会造成重复开发产生非常多的冗余代码。那么这个时候就引入了服务化改造的思想，把一些通用的、会被多个上层服务调用的模块独立拆分出来，形成一些共享的基础服务。SOA 的核心目标就是通过服务的流程化来实现业务的灵活性，SOA 中更强调 ESB 企业服务总线，企业服务总线可以使得服务之间的交互是动态的，以及服务位置是透明的。这样的好处是服务的调用者和服务的提供者之间是高度解耦的。
微服务
微服务并不是一种新思想的方法。它更像是一种思想的精炼，是一种服务化思想的最佳实践方向而已，SOA强调粗粒度划分服务，而微服务强调更细粒度的划分也就是服务的职责更加单一更加精炼 我们也可以把 SOA 看成是微服务的超集。 也就是多个微服务可以组成一个 soa 服务。如下为Dubbo官方中给出的一个服务演化的图示：
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
