后台技术框架预研 - 架构设计原则

接到一个新的项目，本来是要做大数据平台的架构师工作，但是目前还没有数据和相关资源。
所以先把后台的技术给先预研起来吧。也在这里给大家做个分享，为开发者社区贡献自己的绵薄之力。

后台架构设计原则：

第一、架构方面不同阶段够用即可，禁忌全技术的视角做出过渡的设计，大道至简。一切都是寻序渐近的，不断的应对变化不断的改变，因为你并不知道你后期会变成什么样，所以你开始的过度设计可能并不能完全符合后期的发展，甚至会面目全非。其实即使是不过度设计也难逃帕累托原则，就是你80%的工作结果只来自于你20%的工作量。

第二、要预先考滤好后期的业务目的，架构要能够灵活扩展，减少架构升级的成本。（没有最好的架构，只有最适合的架构，一切要基于你的业务而定）

第三、语言选择，首先要能满足你的业务需求，其次看趋势，再次看开发成本、生态、开发者够不够多，尤其是互联网应用服务框架，要特别注意性能方面的考量
另外我个人比较排斥语法糖较多的语言，十人九风格的编码给团队协作带来不小的麻烦（没有最好的语言，根据你的业务和团队现状来定吧）

第四、环境，众所周知整个软件生产过程是非常敏锁的，涉及到整个团队的协作、产能、敏捷和质量。所以做为一个架构师并不能仅仅从开发者的角度出发去考滤问题，当然这整套工作可以由一个全能者来负责，也可以由团队协作来完成。整个主线过程包括开发、测试、灰度上线、发布，另个在这个主程过程中你还需要做CI(持续集成)/CD(持续部署)、自动化测试甚至是代码质量的自动化检测
在一个出道不久的coder看来做了那么多的事情有些没必要，但是你要知道code的目标并不是为了code，而是你要完成一个目标、一个用户故事，这过程中涉及到团队协作、质量把控、去除重复的劳作部分让机器去帮助你完成

---------------------------
以下是技术细节相关
---------------------------

第五、三大分离原则 ：动静分离、读写分离、前后分离
动静分离： 指的是动态和静态页面，对于静态页面是可以有相应的技术来加速的，如CDN、nginx、squid/varnish ; 动态页面是指不同的用户不同的场景都会产生不同的页面。 预测本项目几乎不会有静态页面，所以此部分不详细说明了
读写分离：就是把数据库分为主从库，主库负责写从库负责读，这样可以分流一些主库的压力。 也有人对主从分离并不是很认可，认为采用缓存技术会更直接一点，毕竟读写分离有潜在的一致性以及有故障牵移等问题，但是这些还是要看项目需要吧，如果我要对数据做定期快照至数据平台的话，读库还是非常有必要的
前后分离：就是前台后台分离
第六、负载均衡原则和平滑扩容，当服务过载了，需要能够方便的做到负载均衡扩展
第七、破除服务依赖原则，与第三方对接时要做好监控和服务过载保护等挫失

第八、服务间能用异步的尽量使用异步原则

服务架构设计原则很多，但是能帮助你完成高质量、持续运行目标的就是最好的，所以这里我只列出这些供大家参考