服务器后台开发中的一点经验

现在服务器后台开发，最常见的估计就是SSM和SSH两种架构。同时在架构中使用缓存和隔离技术，提高系统的性能。

首先，前端的目前比较普遍的一个原则是：静态页面替代动态页面。原因有两点：一是由于JavaScript脚本推出的V8引擎，极大地提升了解释执行能力。二是静态页面适合缓存和切分，适合目前的服务器缓存和CDN技术；同时也和后台服务器直接解耦，保证前端和后台开发的独立性。

第二点是，能不用并发编程的地方坚决不使用并发处理。因为，软件发展的一个趋势是主要关注功能，性能上的考虑交给部署和运维。并发可以提升性能，但是同时也由于资源的切换和锁，线程的调度，并发的一致性保障所付出的额外考量，导致并发在运行中的不稳定。举个栗子Node.js 使用的单线程和异步事件，在目前看来架构也是相当优雅，而且性能也不错。

第三点，数据为王。所有的服务开发最终其实都是为数据服务，因此服务只能是数据的依附。服务可以定义一种模型去描述数据，让数据按照其中的一种模式去使用和维护。服务的切分要完全依据数据的类别。服务的开发，首先要满足单一性原则。一个服务尽量只做自己应该做的事情。在一类数据之间尽量发生内部关系，与其他类的数据只能发生外部关系。最终的结果是，有利于服务的切分，也有利于数据的切分。最终可以达到系统的可伸缩能力。

第四点，简洁的是最好的。数据库设置了一系列的规则，但是数据库的规则其实限制了它的性能提升。在设计上，数据库应该回归到它原始的功能，数据存储。对于数据之间的关系，应该是业务需要考虑的问题。因此，在数据表的设计中，抛弃索引，抛弃外键，抛弃集合操作。数据真正需要关心的是数据的类型，数据的简单计算，数据的锁定粒度。

第五点，数据的缓存改变性能。数据的缓存是为了极大的解放服务而存在的。首先，冷数据（读多写少）的缓存。冷数据在系统中是应用最广的一种场景，在响应性能上内存>统一缓存>数据库。同时数据一致性方面，内存<统一缓存<数据库。所以，最终选择怎样的缓存，依赖于业务对响应性能和一致性两方面的偏向。对于热数据，由于数据的生命周期短，所以数据的某一时刻数据的准确性不是最关键的，因此任何可以快速计算的方式都是最佳的选择。

第六点，在保证以上环节之后，最重要的就是服务部署的解耦、分布式的扩展性和持续性。一个合适的部署方案，既能保障数据的安全，同时也能较好的扩展。同时，在使用各种分布式软件时。首先设置分布式软件的中等配置，然后去调整服务的响应性能，然后最终去调整分布式软件的瓶颈。目前最通用的分布式为Nginx、keepalived、zookeeper等。

待续（2016年7月21日22:34:31）