架构小而美的实践
架构演进
- 原始阶段，狂狂堆代码，后来有人骂娘了
- 于是开始分层，mvc，甚至dao，service，还有rails里比较比较好的Concerns等
- 然后模块化，按功能拆分
- 服务化，当功能太多的时候，大家开始探索SOA，把服务挂到ESB上以期一统江湖
- 提高资源利用率，虚拟化，云计算的特点之一
- 到目前后端基本已经很成熟了，于是开始前端分层，mvc，mvvm等…
我们来审视一下这个演进过程，从刚开始到一个复杂的系统，是每个团队都有经历，甚至复杂到一定程度，连开发都不是知道改怎样去改，太庞大，太复杂了。所以大伙又开始拆分，模块也好，服务也好，都是让它变小，可控，当然这样得益于云计算（后面会讲为什么）。
这里面最重要的变动是从模块化到多个应用并行。避免大而全，而是小而美，如果需要可以建ESB,然后一个门户就可以很好整合这些服务了。
小而美的架构是当下的主流
- 拆分成多个应用，可以组装，也可以横向扩展
- 选择简单的技术，将一件事儿做到极致，开发，测试，运维都非常简单，相对而言增加了运维的复杂程度，但有了docker，让我们轻松了许多
- 避免单点以及其他运维故障，比如数据库锁升级致使瘫痪的解决方法是尽可能分库，降低锁风险，如果每个应用使用自己的库就非常简单了
- 集成容易
- 数据方面，分应用，分库，会导致数据分散，难处理。现在以后有比较成熟的技术，比如使用ETL或消息队列MQ延时同步到hadoop平台，数据仓库或者搜索引擎库，利用SQL、MR或者其他技术进行数据处理，如果是实时业务，也问题不大，共享hbase等都可以解决
我们为什么要选择这样的架构？
- 招聘难
目前为止所有人的反馈都是招聘难，bat无耻的把握了大部分精英资源，中小公司又想以低成本招人，另外还有一点是现在的程序员素质良莠不齐，好像谁找不着工作，去培训3个月就能干了一样。
既然现实已经这样了，那么我们能做啥呢？
- 降低开发难度，【哲学：一次只做一件事儿】，会比较简单，也比较容易做好，而且集成、维护成本等都比较低
- 增加团队技术的多样性，【哲学：做一件事儿不只有一种方法】，不管是java也好，php也好，ror，node，python，go都好，只要稳定，易于上手的都可以考虑用。比如ruby的sinatra，比如scala的scalatra，比如node的express和koa，比如go的Martini，都非常简单，性能都不错的
我们的最终目标是快速交付，快速上线，以期在商业博弈中占点先手优势，而已。
- 运维难
既然拆了这么多应用，实际上部署运维的难度是增大的，但是好处也是很明显
- 云服务越来越多，降低我们很多的运维成本，比如mysql，cdn，redis等都有现成可用的服务
- 利用docker，可以快速部署上万台服务器，甚至更多，另外docker还有一个好处是预置了某种开发环境，只要准备一次配置文件，以后只管创建镜像即可。比如我的scalatra和express运行环境不一样，我只要建2个配置，根据我的业务需求，哪个服务需要加到支持，我就多建一些镜像即可。如果是传统的服务器，想想就想去天台
- 小步快跑难
技术部门很难的2点：
- 开发速度
- 执行速度
假定我们认可agile，无论什么样sprint迭代，我们都要快速交付
核心业务
其实对于多个系统而言，model是最业务核心
多模块
express的好处是可以把app当成子模块，路由可以挂载到当前app上
拆与合
拆的好处
- 模块化和复用
言必称复用，就好像不谈oo和dp都不好意思说是开发一样。
- 更多利好
比如
面向服务
语言的意义
这让我想到2个编程语言的哲学
- There’s More Than One Way To Do It 做一件事儿不只有一种方法
- Do one thing at a time, and do it well 一次只做一件事，并做到最好！
全文完
欢迎关注我的公众号【node全栈】
