想象下这么个场景：
有个做生活服务的APP，主要提供一些生活化的咨询信息，比如天气、新闻、个人三金账单、政府办事事项等等，那么把这些功能全部放入一个应用肯定是不现实的。
按照分布式服务的设计理念，可能最终的结果是用户登录、注册相关的作为一个user应用，天气相关的一个weather应用，新闻资讯相关的一个news应用，账单相关的一个bill应用，政府办事相关的一个life应用，这样就被拆分成了若干个功能相对稳定的应用，同时应用之间通过RPC调用，共同构成了一个分布式服务框架。
这种分布式服务架构在流量、服务数量相对小的时候足够满足实际需要，但是在服务数量越来越大、流量增大或者间断性流量出现峰值、服务间调用越来越复杂的情况下，这种架构就就很难再满足需要了。比如上述的APP这周搞推广注册送礼的活动，突然间登录、注册的操作暴增，此时负责处理相关业务的user应用负荷增加，出现响应慢、超时、宕机的情况，怎么办？按分布式服务框架，最简单直接的办法是增加user应用的实例、带宽等硬件资源，再在调用方或者Nginx端改改user应用相关的负载列表，重启over。等推广结束之后再改改负载列表，停掉增加的资源，重启over.......
如此一来，反复地增加、删除、停止、启动，只要中间某一步做错，就会造成难以想象的错误。那么如何弹性、动态地计算所需资源，又如何动态地增加、删除资源，最大程度不影响业务流转，减少犯错误的几率，是一个新的课题。由此流动式的架构理念运用而生，而dubbo框架正是流动式计算架构的一种。
作者：点融黑帮
链接：https://www.jianshu.com/p/f9ba4ecfebd9
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
网友评论