喝口可乐聊聊可扩展性设计

      可扩展性要达到的目的就是在扩展软件功能、增加项目运行时性能的时候，能尽量少的去改动原有的代码，架构等，基于这个目的，我们在架构设计的时候，需要做到下面的标准。

0x1 可扩展性设计标准

1. 代码功能模块之间耦合度尽量低，比如插件化设计

2. 源码结构性好，层次，目录分明

3. 遵守正向性设计，纵向切割功能模块，封装成单独的服务

上面是标准，那可以用什么手段去达到上面的标准呢？

0x2 可扩展性设计的手段

1. 面向源码接口编程，每一个功能模块都有固定的调用接口，模块之间只要按照规范调用接口就可以了，不用关心实现。类似interface，implement的设计，如依赖注入，代理模式等设计模式，一些著名的开源项目往往会应用上多种设计模式，就是这个目的。不过我相信不少coder用设计模式主是为了“优雅”，”扩展性设计“只是一个附带的效果，毕竟这样才显得逼格比较高，“优雅”是玄学，等于是“我不喜欢钱，但是钱自然就赚了”,  就问你牛不牛 strings.Sprintf("A%sC", ?)   // 牛*好像是敏感词，请自行格式化这个字符串

2. 源码结构这个要视不同的项目而定，例如我们web开发在前后端分离之前的主流架构MVC（现在还有很多web项目是采用MVC架构的），就是按照M-V-C三层去组织代码，通常实现了MVC架构的框架源码架构如下：

在这样架构分明的源码之下，随着业务需求的发展，想扩展哪块功能都能明确指向源码的哪个模块，利好项目的扩展性。

3. 第三点基本上就是微服务的味道了，我们都知道微服务的初衷就是为了让服务隔离，使不同的服务之间减少耦合度，单独为本身的功能负责，通过标准的调用方式供其他服务调用。从利于扩展性设计的角度来看，服务要纵向切割，纵向就表现深度自治，各自管理自己独立的某一类型的功能模块，比如一个电商系统，订单、商品、用户可以单独分为三个不同的服务，当只需要修改订单功能时，我们只需要动订单的服务代码仓库就好。项目运行时，当商品服务的并发比较大的时候，我们可以只增加商品服务的服务节点资源就好（当然由此而带来的其他架构设计、代码复杂度等问题不在此讨论范围内）。

0x3 总结

可扩展性设计本人觉得总结来说，基本的标准是有的，不过具体也要看具体的项目而具体分析，需要根据项目本身的业务需求而去权衡这个“可扩展性设计”的度究竟在哪里，毕竟凡事都得有个度，你写个“hello world"你也扯什么“扩展性设计”那就没啥意思了，本文只是抛砖引玉，是自己的一些总结，不足之处多多包涵，期盼指导共同进步，打完收工。