任何一个网站在发布初期几乎都不可能立马就拥有庞大的用户流量和海量数据，都是在不停的试错过程中一步一步演变其自身架构，满足其自身业务。比如现在能够抗住双十一这么大流量的淘宝，它的技术最早用的是LAMP（Linux+Apache+Mysql+Php）。
随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，急需一个治理系统确保架构有条不紊的演进。
1.单体架构
实际上，架构越复杂，意味着业务的体量越庞大。 对于一个刚刚起步的项目，我们会选择最简单最快速的方式来实现。而单体架构是最好的选择，目前很多的传统软件行业仍然采用这类的架构。 一般的实施方案是，把所有的功能模块都打包在一个（jar、war），并且部署在一个web容器 下，比如tomcat、weblogic、jboss中运行
集群部署方式
一旦用户量以及流量开始增加，服务器的性能就会遇到瓶颈，这个时候必须要对系统架构做调整以及优化。而在这个阶段主要需要解决的问题是提升业务系统的并行处理能力，降低单机系统负载，以便支撑更多的用户访问操作。
集群就是一种很好的方式，它可以把多台独立的服务器通过网络连接进行组合，对外形成一个整体提供服务。当一台服务器的处理能力接近或已超出其容量上限时，我们不会去尝试换一个更高性能的服务器，因为投入产出比不高，一般的做法就是采用集群技术，通过增加新的服务器来分散并发访问流量，只要业务系统能够随意支持服务器的横向扩容，那么从理论上来说就应该无惧任何挑战，从而实现可伸缩性和高可用性架构。
2.分布式架构
虽然通过集群可以提升并行处理能力以及对于高可用的实现，但是同时还需要考虑到业务的复杂度，如果仍然把所有的业务逻辑全部耦合在一起放在一个war包中来管理，那对于代码的维护和扩展来说是非常困难的。而且如果某个业务功能出现故障，会导致整个系统不可用。
所以这个阶段要做的就是降低业务的耦合度，提升系统的容错性。 因此，这个时候可以对业务进行拆分，简单来说，可以按照系统的业务功能拆分出多个业务模块，比如电上网站，会拆分出：首页、用户、搜索、订单、支付、商品等子系统。 每个子系统由不同的业务团队负责。
分布式架构即，将应用不同模块分别部署在不同的服务器上，并通过网络进行通信、协调各模块完成对应的功能。
还可以把一些通用的、会被多个上层服务调用的模块独立拆分出来，形成一些共享的基础服务。这些被拆分出来的共享服务相对来说是比较独立，并且可重用。 比如用户管理服务，包含用户注册、用户查询等功能。比如单点登录服务。
分布式与集群
分布式是一种应用架构，集群是一种应用部署方式，分布式服务的每一个节点都可以部署成单机或者集群。但在实际开发中，为了避免某个服务节点宕机后，导致所有依赖它的服务都不能正常运行，最终使整个分布式系统不可用，一般都会将服务部署成集群模式。简单说，分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。
3.SOA架构
SOA（面向服务架构），从语义上说，它与面向过程、面向对象、面向组件一样，是一种软件组建及开发的方式。SOA 集成了独立部署和维护的服务，并允许它们相互通信和协同工作，以构建一个跨不同系统的软件应用。
那么它们是如何通信和协同工作的呢？ESB（Enterprise Service Bus，企业服务总线）把企业中各个不同的服务连接在一起。就像计算机总线一样，把计算机的各个不同的设备连接在一起。
采用 SOA 架构后，ESB屏蔽各个系统间的异构性，并有公共的服务路由、异常处理、协议转换等功能，满足不同系统服务间的互联互通。各个服务是相互独立运行的，甚至都不清楚某个服务到底有多少对其他服务的依赖，减少各个服务间的依赖和互相影响，做到了松耦合。
4.微服务架构
业务系统实施服务化改造后，原本共享的业务被拆分，形成可复用的服务，可以在最大程度上避免共享业务的重复建设、资源连接瓶颈等问题出现。那么那些被拆分出来的服务，是否也需要以业务功能为维度来进行拆分，使之能够独立进行部署，以降低业务藕合和提升容错性呢？
微服务并不是一种新思想的方法。它更像是一种思想的精炼，是一种服务化思想的最佳实践方向而已，所以可以认为微服务其实是在SOA思路下，随着各个企业对于服务化治理上不断的完善，以及对软件的交付链路以及基础设施逐步成熟之下的一种自然的产物。
微服务和 SOA 架构的区别？
- SOA 关注的是服务的可重用性、以及解决企业内部的信息孤岛问题；微服务关注的是解耦，解耦和可重用性在特定的角度来看是一样，但本质上是不同的。解耦是降低业务之间的耦合度（也就是微服务关注的服务粒度），而可重用性关注的是服务的复用
- 微服务会使用更轻量级的通信协议，使用Restful风格的API。轻量级协议可以很好的支持跨语言，是的语言生态更加丰富
- 微服务会更多的关注Devops的持续交付，因为服务粒度更细使得开发运维变得更加重要。 所以微服务对于容器化技术的结合更加紧密
- 总结来讲，就是微服务承继了SOA面向服务拆分的核心思想，并随着演化，去掉了ESB，结合了新兴的DevOps理念和容器化等基础设施发展优势，将服务拆分做的更彻底。所以他们的关系大概如下，是交集的关系。
为了避免每个服务都需要自己实现一套分布式系统通信的语义功能，随着技术的发展，一些面向微服务架构的开发框架出现了，如Twitter的Finagle、Facebook的Proxygen以及Spring Cloud等等，这些框架实现了分布式系统通信需要的各种通用语义功能：如负载均衡和服务发现等，因此一定程度上屏蔽了这些通信细节，使得开发人员使用较少的框架代码就能开发出健壮的分布式系统。
5.ServiceMesh
虽然已经有了成熟的微服务框架，但它们也存在一些本质问题：
- 虽然框架本身屏蔽了分布式系统通信的一些通用功能实现细节，但开发者却要花更多精力去掌握和管理复杂的框架本身，在实际应用中，去追踪和解决框架出现的问题也绝非易事；
- 开发框架通常只支持一种或几种特定的语言，回过头来看文章最开始对微服务的定义，一个重要的特性就是语言无关，但那些没有框架支持的语言编写的服务，很难融入面向微服务的架构体系，想因地制宜的用多种语言实现架构体系中的不同模块也很难做到；
- 框架以lib库的形式和服务联编，复杂项目依赖时的库版本兼容问题非常棘手，同时，框架库的升级也无法对服务透明，服务会因为和业务无关的lib库升级而被迫升级；
因此以Linkerd，Envoy，NginxMesh为代表的代理模式（边车模式）应运而生，这就是第一代Service Mesh，它将分布式服务的通信抽象为单独一层，在这一层中实现负载均衡、服务发现、认证授权、监控追踪、流量控制等分布式系统所需要的功能，作为一个和服务对等的代理服务，和服务部署在一起，接管服务的流量，通过代理之间的通信间接完成服务之间的通信请求，这样上边所说的三个问题也迎刃而解。
