hsf 架构_java分布服务：我打赌，没人可以这么精短的讲出分布服务架构吧

分布式服务架构诞生背景：

在一个不断发展的大型应用中，新的业务需求和功能不断增加，技术也在不断演进，不同团队构建的功能子系统采用的技术架构五花八门，子系统之间的开发、部署和运维模式也存在较大差异。如果企业内部没有统一的服务框架进行技术层面的拉通，开发和运维效率都将受到很大制约。

传统垂直架构改造的核心就是要对应用进行服务化，服务化改造用到核心技术就是分布式服务框架。

分布式服务：

分布式服务顾名思义服务是分散部署在不同的机器上的，一个服务可能负责几个功能，是一种面向SOA架构的，服务之间也是通过rpc来交互或者是webservice来交互的。逻辑架构设计完后就该做物理架构设计，系统应用部署在超过一台服务器或虚拟机上，且各分开部署的部分彼此通过各种通讯协议交互信息，就可算作分布式部署，生产环境下的微服务肯定是分布式部署的，分布式部署的应用不一定是微服务架构的，比如集群部署，它是把相同应用复制到不同服务器上，但是逻辑功能上还是单体应用。

分布式服务架构与微服务的区别：

分布式服务架构强调的是服务化以及服务的分散化，微服务则更强调服务的专业化和精细分工；从实践的角度来看，微服务架构通常是分布式服务架构，反之则未必成立。所以，选择微服务通常意味着需要解决分布式架构的各种难题。
微服务相比分布式服务来说，它的粒度更小，服务之间耦合度更低，由于每个微服务都由独立的小团队负责，因此它敏捷性更高，分布式服务最后都会向微服务架构演化，这是一种趋势，不过服务微服务化后带来的挑战也是显而易见的，例如服务粒度小，数量大，后期运维将会很难。

服务化架构演进图：

MVC：当业务规模很小时，将所有都部署在同一个进程中，通过双机或者前置负载均衡器实现负载分流；此时，用于分离前后台逻辑的MVC架构是关键。

RPC：当垂直应用越来越多，应用之间交互不可避免，将核心和公共业务抽取出来，作为独立的服务，实现前后台逻辑分离，此时，用于提高业务复用及拆分的RPC框架是关键。

SOA：随着业务发展，服务数量愈来愈多，服务生命周期管控和运行状态的治理成为瓶颈，此时用于提升服务质量的SOA服务治理是关键。

微服务：随着敏捷开发、持续交付、DevOps理论的发展和实践，以及基于Docker等轻量级容器（LXC）部署应用和服务的成熟，微服务架构开始流行，逐渐成为应用架构的未来演进方向。通过服务的原子化拆分，以及微服务的独立打包、部署和升级，小团队敏捷交付，应用的交付周期将缩短，运维成本也将大幅下降。

应用从集中式到分布式：

对于集中式的应用，当业务和功能越来越多为应付大流量、高并发的用户访问问题，只能通过增加硬件来满足应用的低延时和高吞吐量。

利用硬件进行扩容只能暂时顶住冲击，但是遇到棘手问题将无法只是扩容这么简单：

（1）业务不断发展
（2）代码复用是难题
（3）敏捷持续交付面临巨大挑战

解决此类问题的有效方案就是进行横向与纵向的拆分：

纵向拆分：根据业务特性将应用拆分，不同业务模块独立部署。

横向拆分：将核心、公共业务拆分出来，通过分布式服务框架对业务进行服务化，消费者提供标准的契约来消费这些服务。服务提供者独立打包、部署和演进，与消费者解耦。

服务治理：

使用RPC服务框架对业务进行拆分之后，随着服务数增多，就需要进行服务治理，有效管控服务，提升服务运行期质量，防止业务服务代码架构腐化。

分布式服务框架：

Dubbo、HSF、Coral Service等。

原文链接：https://blog.csdn.net/qq_41723615/article/details/90205947