分布式服务架构诞生背景：
在一个不断发展的大型应用中，新的业务需求和功能不断增加，技术也在不断演进，不同团队构建的功能子系统采用的技术架构五花八门，子系统之间的开发、部署和运维模式也存在较大差异。如果企业内部没有统一的服务框架进行技术层面的拉通，开发和运维效率都将受到很大制约。
传统垂直架构改造的核心就是要对应用进行服务化，服务化改造用到核心技术就是分布式服务框架。
分布式服务：
分布式服务顾名思义服务是分散部署在不同的机器上的，一个服务可能负责几个功能，是一种面向SOA架构的，服务之间也是通过rpc来交互或者是webservice来交互的。逻辑架构设计完后就该做物理架构设计，系统应用部署在超过一台服务器或虚拟机上，且各分开部署的部分彼此通过各种通讯协议交互信息，就可算作分布式部署，生产环境下的微服务肯定是分布式部署的，分布式部署的应用不一定是微服务架构的，比如集群部署，它是把相同应用复制到不同服务器上，但是逻辑功能上还是单体应用。
分布式服务架构与微服务的区别：
分布式服务架构强调的是服务化以及服务的分散化，微服务则更强调服务的专业化和精细分工；从实践的角度来看，微服务架构通常是分布式服务架构，反之则未必成立。所以，选择微服务通常意味着需要解决分布式架构的各种难题。
微服务相比分布式服务来说，它的粒度更小，服务之间耦合度更低，由于每个微服务都由独立的小团队负责，因此它敏捷性更高，分布式服务最后都会向微服务架构演化，这是一种趋势， 不过服务微服务化后带来的挑战也是显而易见的，例如服务粒度小，数量大，后期运维将会很难。
以上部分内容摘自文献：
https://sq.163yun.com/ask/question/239168674295271424
https://blog.csdn.net/zhonglunsheng/article/details/83153451
服务化架构演进图：
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
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。