大家好，欢迎来到IT知识分享网。
服务框架是系统从集中式过渡到分布式的基础服务和条件，需要在分布式系统之前就迁移、准备完毕；服务框架是解决应用服务化的问题
3.1 网站功能持续丰富后的困境和应对
一个网站在经历一个快速发展的时期，当每天有百万级别的有效访问量(购网网站的成交单数量)；系统基本会演化成下面的系统：
系统按照功能分成几个“巨大”的应用，每个应用都可以访问底层的基础系统；比如db/分布式缓存、搜索系统、分布式文件系统,应该说这样的结构足够的清晰、简单、解决大部分问题.
但是随着访问量的持续增加，最简单的方式是增加应用的机器，但是这样会增加DB 的压力，因为主要一台DB 支撑写，所以最终还是要进行DB中间件进行分库、分表；随着开发人员越来越多，每个应用的代码也变的无比巨大、臃肿；很多重复、冗余的代码。这样就会采取分拆应用的方案，应用分拆有2种方案：
- 简单的分拆应用，所有应用都直接访问底层系统
这样的分拆简单，但不能解决数据库的连接压力和代码重复、冗余的问题，所以采用下面的一种方案
- 在应用和底层系统中间加上一层服务层
这就是我们说的服务化的方案，在应用层和底层数据库层加上服务层，真正系统中服务层可能是多层，彼此之间可以相互调用。
服务化的优点：－-> 可以理解为微服务化
- 从整体结构上看：架构更清晰、更立体
- 稳定性上看：散落在各个应用中重复的代码也变成了服务，有统一的团队进行维护；保证代码的质量
- 因为服务的代码稳定、发布次数也会变少或者限制，一定程度上也增加了系统的稳定性
- 底层的系统资源也由服务层统一管理，结构清晰、提高效率
- 高扩展性：随着业务的发展，应用数量会越来越多，服务化后可以让应用更加快速的开发 【中台策略】
3.2 服务框架的设计与实现
3.2.1 应用从集中式走向分布式遇到的问题
先来看看服务框架要解决的问题：
在做服务框架时，我们用的最基础的知识是网络通信，在远程网络通信时我们需要把发送的数据进行编码，服务端收到请求数据先解码然后进行相关的处理；
- 单机单进程的调用
- 远程服务、调用客户端
- 服务端的伪代码实现：
3.2.2 RPC 调用的流程方式
免责声明：本站所有文章内容,图片，视频等均是来源于用户投稿和互联网及文摘转载整编而成，不代表本站观点，不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益，请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权，请联系删除，如若转载，请注明出处：https://haidsoft.com/146897.html
