互联网应用架构发展
随着用户群体逐渐扩大，网站的流量成倍增长，常规的单体架构已无法满足请求压力和业务的快速迭代，下面我们以一个招聘系统为例，从最开始的单体架构分析，一步步演变到现在的微服务架构。
单体应用架构
最初，用户量、数据量规模都比较小，项目所有的功能模块都放在一个工程中编码、编译、打包并且部署在⼀个Tomcat容器中，这种架构模式就是单体应用架构，这样的架构既简单实用、便于维护，成本又低，成为了当时的主流架构方式。
优点：
- 项目前期开发节奏快，团队成员少的时候能够快速迭代。
- 架构简单：MVC架构，只需要借助IDE开发、调试即可。
- 易于测试：只需要通过单元测试或者浏览器完成。
- 易于部署：打包成单⼀可执行的jar或者打成war包放到容器内启动。
缺点：
- 随着不断的功能迭代，单个项目过大，代码杂乱，耦合严重，开发团队逐渐壮大以后，沟通成本变高，如：代码从编译到启动耗时达到3-5分钟。
- 新增业务困难：在冗杂的系统中增加新业务，维护旧功能，全是不可预测的问题。新人来了以后很难接手任务，学习成本高，需要⼤概一周时间才能上手开发。
- 核心业务与边缘业务混合在一块，出现问题互相影响，如：一个临时活动流量猛涨，机器负载升高就会影响正常的业务服务。
业务量上涨之后，单体应用架构进一步丰富变化，比如应用集群部署、使用Nginx进行负载均衡、增加缓存服务器、增加文件服务器、数据库集群并做读写分离等，通过以上措施增强应对高并发的能力、应对一定的复杂业务场景，但依然属于单体应用架构。
垂直应⽤架构
为了避免上⾯提到的那些问题，开始做模块的垂直划分，做垂直划分的原则是基于现有的业务特性来做，第⼀个核⼼⽬标是为了业务之间互不影响，第⼆个核⼼⽬标是在研发团队壮⼤后提⾼效率，减少之间的依赖。
优点：
- 系统拆分实现了流量分担，解决了并发问题。
- 可以针对不同模块进⾏优化。
- ⽅便⽔平扩展，负载均衡，容错率提⾼。
- 系统间相互独⽴，互不影响，新的业务迭代时更加⾼效。
缺点：
- 服务之间相互调⽤，如果某个服务的端⼝或者ip地址发⽣改变，调⽤的系统得⼿动修改配置文件。
- 搭建集群之后，实现负载均衡⽐较复杂，如：内⽹负载，在迁移机器时会影响调⽤⽅的路由，导致线上故障。
- 服务之间调⽤⽅式不统⼀，基于httpclient、webservice，接⼝协议不统⼀。
- 服务监控不到位：除了依靠端⼝、进程的监控，调⽤的成功率、失败率、总耗时等这些监控指标是没有的。
SOA应⽤架构
在做了垂直划分以后，模块随之增多，维护的成本在也变⾼，⼀些通⽤的业务和模块重复的越来越多，为了解决上⾯提到的接⼝协议不统⼀、服务⽆法监控、服务的负载均衡，引⼊了阿⾥巴巴开源的Dubbo ，⼀款⾼性能、轻量级的开源Java RPC框架，它提供了三⼤核⼼能⼒：⾯向接⼝的远程⽅法调⽤，智能容错和负载均衡，以及服务⾃动注册和发现。
SOA (Service-Oriented Architecture)，即⾯向服务的架构。根据实际业务，把系统拆分成合适的、独⽴部署的模块，模块之间相互独⽴（通过Webservice/Dubbo等技术进⾏通信）。
优点： 分布式、松耦合、扩展灵活、可重⽤。
缺点： 服务抽取粒度较⼤、服务调⽤⽅和提供⽅耦合度较⾼（接⼝耦合度）。
微服务应⽤架构
微服务架构可以说是SOA架构的⼀种拓展，这种架构模式下它拆分粒度更⼩、服务更独⽴。把应⽤拆分成为⼀个个微⼩的服务，不同的服务可以使⽤不同的开发语⾔和存储，服务之间往往通过Restful等轻量级通信。微服务架构关键在于微⼩、独⽴、轻量级通信。
微服务是在SOA上做的升华，粒度更加细致，微服务架构强调的⼀个重点是“业务需要彻底的组件化和服务化”。
微服务架构和SOA架构相似⼜不同：
微服务架构和SOA架构很明显的⼀个区别就是服务拆分粒度的不同，但是对于一些架构发展来说，我们所看到的SOA阶段服务拆分粒度相对来说已经⽐较细了，所以上述SOA到微服务，从服务拆分上来说变化并不⼤，只是引⼊了相对完整的新⼀代的Spring Cloud微服务技术。所以，上述我们看到的都是架构演变的阶段结果，每⼀个阶段其实都经历了很多变化，服务拆分其实也是经过了从粗到细，并⾮绝对的⼀步到位。
例：我们在SOA架构的初期，“简历投递模块”和“⼈才搜索模块”都有简历内容展示的需求，只不过说可能略有区别，⼀开始在两个模块中各维护了⼀套简历查询和展示的代码；后期我们将服务更细粒度拆分，拆分出简历基础服务，那么不同模块调⽤这个基础服务即可。
微服务架构体现的思想及优缺点
微服务架构设计的核⼼思想就是“微”，拆分的粒度相对⽐较⼩，这样的话每个服务具有单⼀职责，开发的耦合度就会降低，微⼩的功能可以独⽴部署扩展、灵活性强，升级改造影响范围⼩（比如升级JDK）。
微服务架构的优点:
- 微服务很⼩，便于特定业务功能的聚焦.
- 微服务很⼩，每个微服务都可以被⼀个⼩团队单独实施（开发、测试、部署上线、运维），团队合作在⼀定程度上解耦，便于实施敏捷开发。
- 微服务很⼩，便于重⽤和模块之间的组装。
- 微服务很独⽴，不同的微服务可以使⽤不同的语⾔开发，松耦合。
- 微服务架构下，更容易引⼊新技术。
- 微服务架构下，我们可以更好的实现DevOps开发运维⼀体化。
微服务架构的缺点
- 微服务架构下，分布式复杂难以管理，当服务数量增加，管理将越加复杂。
- 微服务架构下，分布式链路跟踪难等。
微服务架构中的⼀些概念
服务注册与服务发现
服务注册： 服务提供者将所提供服务的信息（服务器IP和端⼝、服务访问协议等）注册/登记到注册中⼼。
服务发现： 服务消费者能够从注册中⼼获取到较为实时的服务列表，然后根据⼀定的策略选择⼀个服务访问。
负载均衡
负载均衡即将请求压⼒分配到多个服务器（应⽤服务器、数据库服务器等），以此来提⾼服务的性能、可靠性。
熔断
熔断即断路保护。微服务架构中，如果下游服务因访问压⼒过⼤⽽响应变慢或失败，上游服务为了保护系统整体可⽤性，可以暂时切断对下游服务的调⽤。这种牺牲局部，保全整体的措施（即防止雪崩）就叫做熔断。
链路追踪
微服务架构项⽬往往拆分成很多个服务，那么⼀次请求就需要涉及到很多个服务。不同的微服务可能是由不同的团队开发，可能使⽤不同的编程语⾔实现，整个项⽬也有可能部署在了很多服务器上（甚⾄百台、千台），横跨多个不同的数据中⼼。所谓链路追踪，就是对⼀次请求涉及的很多个服务链路进⾏⽇志记录、性能监控。
每一个请求都有一个唯一的taceid来贯穿整个请求链路的始终，tracid会存储到整个调用链路的上下文中，而每个微服务都会有日志系统来记录日志，此时该请求的tracid也会同时被记录到日志中去，通过对每个微服务的日志进行分析，即可进行链路追踪分析问题。
在一个请求贯穿整个链路的过程中，每经过一个微服务的过程称之为块（span），所有的块构成了一个链路，每个块都有一个spanid，用来分析当前微服务的性能指标等。
API⽹关
微服务架构下，不同的微服务往往会有不同的访问地址，客户端可能需要调⽤多个服务的接⼝才能完成⼀个业务需求，如果让客户端直接与各个微服务通信可能出现：
- 客户端需要调⽤不同的url地址，增加了维护调⽤难度。
- 在⼀定的场景下，也存在跨域请求的问题（前后端分离就会碰到跨域问题，原本我们在后端采⽤Cors就能解决，现在利⽤⽹关，那么就放在⽹关这层做好了）。
- 每个微服务都需要进⾏单独的身份认证。
API⽹关就可以较好的统⼀处理上述问题，API请求调⽤统⼀接⼊API⽹关层，由⽹关转发请求。
API⽹关更专注在安全、路由、流量等问题的处理上（微服务团队专注于处理业务逻辑即可），它的功能⽐如：
- 统⼀接⼊（路由）
- 安全防护（统⼀鉴权，负责⽹关访问身份认证验证，与“访问认证中⼼”通信，实际认证业务逻辑交移“访问认证中⼼”处理）
- ⿊⽩名单（实现通过IP地址控制禁⽌访问⽹关功能，控制访问）
- 协议适配（实现通信协议校验、适配转换的功能）
- 流量管控（限流）
- ⻓短链接⽀持
- 容错能⼒（负载均衡）
