分布式服务架构诞生背景:
在一个不断发展的大型应用中,新的业务需求和功能不断增加,技术也在不断演进,不同团队构建的功能子系统采用的技术架构五花八门,子系统之间的开发、部署和运维模式也存在较大差异。如果企业内部没有统一的服务框架进行技术层面的拉通,开发和运维效率都将受到很大制约。
传统垂直架构改造的核心就是要对应用进行服务化,服务化改造用到核心技术就是分布式服务框架。
分布式服务:
分布式服务顾名思义服务是分散部署在不同的机器上的,一个服务可能负责几个功能,是一种面向SOA架构的,服务之间也是通过rpc来交互或者是webservice来交互的。逻辑架构设计完后就该做物理架构设计,系统应用部署在超过一台服务器或虚拟机上,且各分开部署的部分彼此通过各种通讯协议交互信息,就可算作分布式部署,生产环境下的微服务肯定是分布式部署的,分布式部署的应用不一定是微服务架构的,比如集群部署,它是把相同应用复制到不同服务器上,但是逻辑功能上还是单体应用。
分布式服务架构与微服务的区别:分布式服务架构强调的是服务化以及服务的分散化,微服务则更强调服务的专业化和精细分工;从实践的角度来看,微服务架构通常是分布式服务架构,反之则未必成立。所以,选择微服务通常意味着需要解决分布式架构的各种难题。
微服务相比分布式服务来说,它的粒度更小,服务之间耦合度更低,由于每个微服务都由独立的小团队负责,因此它敏捷性更高,分布式服务最后都会向微服务架构演化,这是一种趋势, 不过服务微服务化后带来的挑战也是显而易见的,例如服务粒度小,数量大,后期运维将会很难。
服务化架构演进图:
MVC:当业务规模很小时,将所有都部署在同一个进程中,通过双机或者前置负载均衡器实现负载分流;此时,用于分离前后台逻辑的MVC架构是关键。
RPC:当垂直应用越来越多,应用之间交互不可避免,将核心和公共业务抽取出来,作为独立的服务,实现前后台逻辑分离,此时,用于提高业务复用及拆分的RPC框架是关键。
SOA:随着业务发展,服务数量愈来愈多,服务生命周期管控和运行状态的治理成为瓶颈,此时用于提升服务质量的SOA服务治理是关键。
微服务:随着敏捷开发、持续交付、DevOps理论的发展和实践,以及基于Docker等轻量级容器(LXC)部署应用和服务的成熟,微服务架构开始流行,逐渐成为应用架构的未来演进方向。通过服务的原子化拆分,以及微服务的独立打包、部署和升级,小团队敏捷交付,应用的交付周期将缩短,运维成本也将大幅下降。
应用从集中式到分布式:对于集中式的应用,当业务和功能越来越多为应付大流量、高并发的用户访问问题,只能通过增加硬件来满足应用的低延时和高吞吐量。
利用硬件进行扩容只能暂时顶住冲击,但是遇到棘手问题将无法只是扩容这么简单:(1)业务不断发展
(2)代码复用是难题
(3)敏捷持续交付面临巨大挑战
解决此类问题的有效方案就是进行横向与纵向的拆分:
纵向拆分:根据业务特性将应用拆分,不同业务模块独立部署。
横向拆分:将核心、公共业务拆分出来,通过分布式服务框架对业务进行服务化,消费者提供标准的契约来消费这些服务。服务提供者独立打包、部署和演进,与消费者解耦。
服务治理:使用RPC服务框架对业务进行拆分之后,随着服务数增多,就需要进行服务治理,有效管控服务,提升服务运行期质量,防止业务服务代码架构腐化。
分布式服务框架:
Dubbo、HSF、Coral Service等。