后台系统搭建经验思考

去年部门开始转向云业务，有幸参与一个较大的项目，从0到1开始一个后台系统的建设，从开始规划到进行项目交付，总结梳理一下在这个期间我们的思路是怎样的？

1从无到有

1.1系统定位

只有对系统的定位有比较清晰的认识，才能更好的去设计和实现一个系统，因此在一开始我们需要梳理和明确建设的大方向，确定系统在项目中的定位是什么，系统应该具备的能力有哪些？

1.2架构设计

结合系统的定位和需求，进行合理的架构设计。整个系统的架构设计尽量遵循以下原则：

1.简单但不简陋

需要对整体的需求有清晰的理解，保持系统的简单，但是要同时能保证系统的完备性。

2.合理拆分

复杂的系统最好拆分成简洁的子系统，并保持各个子系统之间职责分工明确，交互清晰。

3.架构的可扩展能力

随着项目推进和系统能力的建设，架构最好具有良好的扩展能力。

1.3技术选型

知道要做什么怎么做以后，使用什么样的工具就很非常重要了，在技术选型阶段需要从以下几方面根据项目实际情况选择适合自己的道路。

1.通信协议

作为一个后台系统，离不开各种网络交互，因此在网络通信上我们怎么选择非常重要。是UDP + protobuf，TCP + protobuf还是HTTP + json。。。需要根据项目实际情况，项目团队技术人员等多方面综合考虑选择最适合自己的。

2.开发语言

系统平台的建设离不开代码，因为选择合适的语言也很重要，从团队的接受度、开发敏捷性和可维护性等多方面综合考虑，选择开发语言。

3.存储选型

后台系统一般都离不开数据存储，只要涉及到数据存储就有很多数据问题需要考虑，了解自己业务数据的特性：是结构化、半结构化还是非结构化数据？数据的量级？是否需要支持事务？数据是多读少写还是频繁写？诸多因素都会影响到我们存储的选型。

在进行技术选型时，一定要考虑技术的成熟度，技术发展是否成熟，是否有成熟的社区支持，是否拥有前进的步伐。这些因素会影响我们的系统建设，同时也会影响以后的运维。总的来说，合理的技术选型是系统的基石。

2系统建设

2.1能力建设

系统除了正常的业务功能外，还需要有一些其他的能力以保证系统的稳定性、可用性和安全性，例如：

1.系统健壮性

接口层增加鉴权和频率统计能力，可以有效的保护系统不被坏人利用和恶意攻击，通过在接口层增加相应的功能保护整个后端系统的安全。后端各个相互调用的子模块之间需要有基本的保护措施，如过载保护和防雪崩等。

2.系统安全性

系统的安全性包含硬件和软件两方面：硬件方面针对我们的服务器我们需要有保护策略，如限制登录访问、防ddos等；软件方面如机器仅开放监听指定对外端口，上线前进行安全漏掉扫描等。

3.数据安全性

不论是读还是写的权限都应该保证最小权限的原则，避免因为权限的不合理分配导致系统的数据泄漏和篡改等危险。同时系统的数据层应该有定期的数据备份能力和数据恢复能力，保证数据在被写坏的情况下能回退到最近的某个正常版本。

4.系统性能

对系统各个子模块进行压测，了解系统各个子模块可支持服务的大致量级，发现系统的瓶颈节点，梳理可提升的点。

2.2质量控制

在系统的建设过程中必然伴随着版本的迭代，在版本迭代的过程中，如何保证系统的服务质量？迭代过程中测试环境和正式环境分离，开发自测和灰度上线等基本操作大家都可以做到，但即使做到这些依旧不能避免事故的发生，因此还需要一些其他工作来保证版本的迭代不影响系统的服务质量，例如：

1.代码review

任何一个模块都至少需要有一主一备，对于新增功能的代码，必须要加入代码review的环节。

2.单元测试

对系统的各个功能点或者是接口增加单元测试的功能，在上线前进行一轮单元测试可以有效的降低事故的发生率，同时还可以尽早的将问题暴露。

3运维

3.1日志

在系统的关键节点记录log，便于我们日常问题的定位。一个好的log系统在搜集阶段应该具有轻量级、易接入和对系统性能损耗小等多优点，log落地支持多样化如果写入本地文件或者是转到远程系统，log查看至少应该要支持web页面查看并且web系统应该支持基本的检索和筛选能力。

3.2系统监控

合理的监控可以让我们时刻了解系统当前运行的状况，如系统的负载、各个接口的调用情况以及机器的内存、硬盘和网络等基础信息的监控。同时为系统中的重要监控属性设置合理的告警阈值，可以让我们在第一时间发现系统的异常，及时进行人工干预保障系统的可用性。

3.3发布部署

引入发布部署系统可以减少人工操作，并且有利于管理系统各个子模块的运行版本。发布部署系统至少应该支持以下能力：

1.灰度/批量发布/回滚

在版本升级的时候可以通过灰度观察上线的新功能是否正常，是否会影响原有的功能，批量发布可以让我们自定义发布的节奏，回滚可以让我们在出现问题时快速回退到某正常版本。

2.多机版本管理

当线上服务有只有较少机器时，人工维护版本统一还比较容易，但是随着规模的增大人工维护成本会越来越高，因此最好是有自动化的工具取代人工。越少的人工介入不仅可以降低人力成本还可以减少犯错的可能。

3.进程状态监控

自动化的进程状态监控完成进程存活状态的监控，同时还需要支持自动化拉起异常退出的业务进程，以保证业务的可使用率，同时减少人工运维工作。

3.4文档建设

如果问程序员最痛恨的事情是什么：接手一个系统没有文档应该可以排前三。所以一个好的系统至少应该具有完备的接口说明文档和系统运维文档。

1.接口说明文档

接口说明文档应该包含系统所有对外接口的调用说明，包括调用方式、调用协议和示例说明等信息。当然文档内容越清晰详细越好，便于调用方快速接入，减少人工答疑和重复劳动，提高工作效率。

2.系统运维文档

运维文档应该包含系统的基本介绍、架构拓扑图和部署等信息，便于接手系统的同事能快速上手，避免“口口相传”带来的信息缺失。

4 总结

上面内容从其中任何一点都可以扩展深入到很大的篇幅，但是很多问题我觉得都需要结合实际项目情况综合多方面的因素考虑，并没有一个标准的“套路”，因为以上只是我在做项目过程中一点自己的认识，可能有很多不足的地方，欢迎大家指正。