可扩展概念

可扩展性：当需求出现变化时，系统不需要或者仅需要少量修改就可以支持，无须推翻原来重新再搞一遍。

划重点：变化，支持

思考：

1. 预测哪块业务流程可能会发生变化？如何变化？

2. 如何来应对可能变化的点？

提炼：预测变化 + 应对变化

如何预测变化？

1. 从产品那了解下一迭代需求是否影响本次开发，例如：本期需求：消息通知是APP推送通知，下一迭代：支持短信通知。所以要做好扩展。---明确
2. 根据个人开发经验和业务理解，预测将来哪块可能会变化。---经验理解，预测
3. 自己搜索/与别人沟通交流，预测将来是否有相应的变化。---了解，预测

综上，明确的变化，必须做好扩展；预测的变化，做好必要的扩展。预测有可能正确，也有可能不正确，切忌多度设计。

如何应对变化？

怎样才能让系统扩展性更好？听最多的一句话就是“这地方不要写死！”，常常会定义个变量，抽象类，接口等等，其实本质就是降低耦合，所以耦合越低，越容易应对变化，越容易扩展。

应对变化的手段：降低耦合，变与不变分开。

降低耦合：分布式消息队列和分布式RPC框架。

变与不变分开： 不变的是什么？ 是参数名，接口类，抽象方法等等。变的是什么？是具体参数值，具体接口实现类，具体方法实现等等。

项目实战

• 【参数变量】- 基于Redis实现动态控制app导航展示：

        String isShowCrowdFunding = redisClient.get(isShowCrowdFundingKey);
        if (isShowCrowdFunding != null && "1".equals(isShowCrowdFunding)) {
            return true;
        } else {
            return false;
        }

• 【钩子函数】- 基于Function和BiConsumer实现日程的月视图和日视图：

private BaseResponse<List<ScheduleMeViewVO>> handleScheduleView(List<ScheduleMe> scheduleMes
            , Function<ScheduleMe,String> groupByFunc, BiConsumer<String,ScheduleMeViewVO> dateFunc){
...............
}

• 【抽象类】-基于模板方法实现多请求合并处理：

public abstract class AbstractRequestHandler implements RequestHandler{

    abstract Object handleParams();

    abstract String buildUrl();

    abstract Object doHandle(String url, Object params, HttpHeaders headers);
}

• 【接口类】-基于SmartInitializingSingleton实现注入接口多实现类：

@Component
public class TradeHandlerFactoryConfig implements SmartInitializingSingleton {

    @Override
    public void afterSingletonsInstantiated() {
        Map<String,ITradeHandler> iTradeHandlerMap = SpringContextHolder.getBeansOfType(ITradeHandler.class);

        if (!CollUtil.isEmpty(iTradeHandlerMap)) {
            iTradeHandlerMap.entrySet().stream().forEach(e->{
                TradeHandlerFactory.add(e.getKey(),e.getValue());
            });
        }
    }
}

相关阅读：

架构篇-一分钟掌握性能优化小技巧

架构篇-一分钟掌握高可用架构

架构篇-一分钟掌握可伸缩架构

大家有好方案，欢迎在评论区留言，共同进步！