微服务架构

一、单体应用架构

优点：
项目前期开发节奏快，团队成员少的时候能够快速迭代
架构简单：MVC架构，只需要借助IDE开发、调试即可
易于测试：只需要通过单元测试或者浏览器完成
易于部署：打包成单一可执行的jar或者打成war包放到容器内启动
缺点：
随着不断的功能迭代，单个项目过大，代码杂乱，耦合严重，开发团队逐渐壮大以后，沟通成本变高，如：代码从编译启动耗时达到3-5分钟
新增业务空难：在已经乱如麻的系统中增加新业务，维护旧功能，一脚踩进去全是不可预测的问题。新人来了以后很难接手任务，学习成本高，需要大概一周时间才能上手开发
核心业务与边缘业务混合在一块，出现问题互相影响，如：一个临时活动流量猛涨，机器负载升高就会影响正常的业务服务
业务量上涨之后，单体应用架构进一步丰富编号，比如应用集群部署、使用Ngninx进行负载均衡、增加缓存服务器、增加文件服务器、数据库集群并做读写分离等，通过以上措施增加应用对高并发的能力、应对一定的复杂业务场景，但依然属于单例应用架构。

二、垂直应用架构

优点：
系统拆分实现了流量分担，解决了并发问题
可以针对不同模块进行优化
方便水平拓展，负载均衡，容错率提高
系统相互独立，胡不影响，新的业务迭代时更加高效
缺点：
服务之间相互调用，如果某个服务的端口或者ip地址发生变化，调用的系统得手动改变
搭建集群之后，实现负载均衡比较复杂，如：内网负载，在迁移机器时会影响调用放的路由，导致线上故障
服务之间调用方式不统一，基于httpclient、webservice，接口协议不统一
服务监控不到位：除了依靠端口、进程的监控，调用率、失败率、总耗时等等这些监控指标是没有的

三、SOA应用架构

在做了垂直划分以后，模块随之增多，维护的成本也在变高，一些通用的业务和模块重复的越来越多，为了解决上面提到的接口协议不统一、服务无法监控、服务的负载均衡，引入阿里巴巴开源的Dubbo，一款高性能、轻量级的开源Java RPC架构，它提供了三大核心能力：面向接口的远程服务调用，智能容错和负载均衡，以及服务自动注册和发现。
SOA(Service-Oriented Architecture),即面向服务的架构。根据实际业务，把系统拆分成合适的、独立部署的
模块，模块之间相互独立（通过Webservice/Dubbo等技术进行通信）。
优点：
分布式、松耦合、拓展灵活、可服用
缺点：
服务抽取粒度较大、服务调用方和提供方耦合度较高（接口耦合度）

四、微服务应用架构

微服务架构可以说是SOA架构的一种拓展，这种架构模式下它拆分粒度更小、服务更独立。把应用拆分成一个个微服务，不同的服务可以使用不同的开发语言和存储，服务之间往往通过Restful等轻量级通信。微服务架构关注在与微小、独立、轻量级通信。
微服务是SOA上做的升华粒度更加细微，微服务架构强调的一个重点是”业务需要彻底的组件化和服务化”。

微服务架构和SOA架构相似又不同
微服务架构和SOA架构很明显的一个区别就是服务拆分粒度的不同，但是对于拉钩的架构发展来说，我们所看到的SOA阶段其实服务拆分粒度相对来说比较细了。所以上述拉钩的SOA到拉钩微服务，从服务拆分上来说变化并不大，只是引入了相对完整的新一代Spring Cloud微服务技术。自然，上述我们看到的都是拉钩架构演变的阶段结果，每一个阶段其实都经历了很多变化，拉钩的服务拆分其实也是走过了从粗到细，并非绝对的一步到位。
举个例子说明SOA和微服务拆分粒度不同
我们在SOA架构的初期，“简历投递模块”和“人才搜索模块”都有简历内容展示的需求，只不过说可能略有区别，一开始两个模块中各维护了一套简历查询和展示的代码；后期我们将服务更细粒度拆分，拆分出简历基础服务，那么不同模块调用这个基础服务即可。