高并发之应用的拆分
前面我们已经提到单个服务器再优化,它的处理能力都是有上限的,因此我们选择多扩容以及使用缓存和消息队列等对程序进行优化。
下面介绍另一种方法,随着项目需求完成越来越多,应用自然也会越来越大,架构师将一个应用整体拆分成多个应用。
拆分的原则:
1.业务优先,确定业务边界
2.循序渐进,边拆分边测试
3.兼顾技术:重构、分层
4.可靠测试
拆分的思考:
1.应用之间的通信:RPC(dubbo等)、消息队列
消息传输适用于传输数据包小但是数据量大,对实时性要求不高的场景。比如下单成功后通过短信通知用户。而选用RPC框架实时性更高一些。你应该知道的 RPC 原理
2.应用之间的数据库设计:每个应用都有独立的数据库
3.避免事务操作跨应用,分布式事务是一个非常消耗资源的问题。这样应用和应用的耦合度降低。
应用拆分:
服务化——Dubbo
微服务——SpringCloud
Dubbo是一种分布式的服务框架
![](https://images2018.cnblogs.com/blog/996415/201807/996415-20180707213632990-1068907628.png)
要实践微服务要解决4个问题:
1.客户端如何访问这些服务
API Gateway提供统一的服务入口,对前台透明,同时可以聚合后台的服务,提供安全过滤流控等api的管理功能
2.服务之间是如何通信的
异步的话使用消息队列,同步调用使用REST或者是RPC,Rest可以使用springboot,RPC通常使用Dubbo
同步调用一致性强但是出现调用问题,REST一般基于http实现,能够跨客户端,同时对客户端没有更多的要求。
RPC的传输协议更高效,安全也更加可控。特别是在一个公司内部如果有统一的开发规范和统一的框架,它的开发效率会更加明显。
而异步消息在分布式系统中有特别广泛的应用,它既能减少调用服务之间的耦合,又能成为调用之间的缓冲,确保消息积压不会冲垮被调用方。
同时保证调用方的用户的体验,继续干自己的活。付出的代价是一致性的减慢,需要接受数据的最终一致性
3. 如何实现如此多服务
在微服务架构中一般每一服务都会拷贝进行负载均衡,服务如何相互感知,如何相互管理,这就是服务发现的问题了,一般都是进行服务注册信息的分布式管理。
4.服务挂了该如何解决,有什么备份方案和应急处理机制
分布式最大的特性就是网络是不可靠的,当系统是由一系列的调用链组成的时候,其中任何一个出问题都不至于影响到整个链路。
相应的手段有:重试机制、应用的限流、熔断机制、负载均衡、系统降级