操作系统

Linux: CentOS 是首选， Ubuntu 或 Redhat 其他系统亦可，不推荐 windows 作为服务器的宿主系统

编程语言

• C或C++ 是首选，适合于计算量大和对性能要求比较高
• Java 对于复杂的业务逻辑比较有优势，只要你对由于 GC 导致的延迟不敏感.
• GO 语言颇有后来居上的势头，只需要发布二进制包，无需解释或执行器，而且跨平台兼容性，性能也不错，内置了并发和网络库也很不错
• 其他脚本语言： python, ruby, nodejs 也可用于性能要求不高的场景

线程模型：

在服务器内部可以划分为如下线程 * 网络线程: Non-blocking IO + IO multiplexing + Event loop per thread * 业务线程: Blocking queue + Thread Pool * 日志和度量事件发送线程：最好和业务线程分开 * 数据库线程

度量框架

我们需要度量如下的关键指标 * 系统资源消耗度量如何? 比如 CPU, 内存, 磁盘及网络 IO 等 * 应用关键指标度量如何? 比如吞吐量和响应时间，成功率等 * 主要业务功能指标如何? 比如并发在线人数，关键功能的使用率等 * 高压力之下的性能如何：在高并发，大压力下的性能表现

而度量代码本身应该是非侵入式的，且对资源的消耗低，不影响主要的业务流程。

高可用机制

• 服务器是否是无状态的，抑或有状态同步机制?
• 有无有健康检查和心跳机制?
• 有无集群内和跨集群的冗余备份?
• 有无分流，限流和断流的机制?
• 能否快速重启，快速恢复?

可用性和一致性的权衡

CAP 理论上是不可同时满足的， 而分布式系统中 Partial Failure 是不可避免的 所以要在Consistence 和 Availability 上做折衷和权衡。

• 一致性的目标是什么？ 例如金融银行领域的业务服务需要强一致性，宁可牺牲一些可用性，而会议服务器可需要更高的可用性，仅需要最终一致性就好了。

• 可用性的目标是什么？

高可性性的指标就是可用时间与总时间之比

availability = uptime/(uptime + downtime)

现在普遍要求可用性至少达到两个九, 最好在四个九以上, 也就是说你的服务要达到如下要求

• 如何权衡可用性和一致性？

高扩展性

业务扩展迅速，如何快速扩展以应对高速增长的流量呢

1. 是否可以通过单纯地增加服务器来应对流量的增长？
2. 是否可以进行水平和垂直拆分？例如 DB sharding, 根据业务实体的主键进行分库分表

安全性

• Authentication 认证要求 - 用户是不是通过认证的合法用户？
• Authorization 授权要求 - 用户是不是经过授权的合法用户, 所访问的模块是在其权限范围之内的？
• Audit 可审查和追溯要求 - 用户的访问和操作是不是可以审查和追溯的？

还有对于用户隐私的保护 * 用户的个人敏感信息 PII (Personal Insentive Information ) 是不是在服务器的日志或数据库中随意存放？

例如密码必须经过不可逆的哈希之后再存储在数据库中, 个人的邮件, 电话等信息均不可存放在日志文件中, 只可以放在有访问限制的数据管理系统中

• 数据在传输层是不是安全的？ 有没有使用 TLS, DTLS 或者 SRTP 进行加密传输？
• 数据在应用层是不是有上述 “3A” 的保护？

API

• 是不是采用标准化的协议？
• 是不是容易理解？
• 是不是容易扩展，向前兼容？
• 是不是可自动生成文档？

网络工具包

我们在选择框架和软件工具包应该遵循 4L 原则

• License is free and open 是不是免费开源的？
• Lots of people use it 是不是有许多人在使用它？
• Lots of successful cases 是不是有许多成功的案例？
• Lots of learn materials 是不是有许多易于学习的资料？

例如，Java 的 Netty 和 C++ 的 Boost 都满足上述原则

Java Netty

• API使用简单，上手快，学习成本低。
• 功能强大，内置了多种解码编码器，支持多种协议。
• 性能优秀，高吞量，低延迟，资源消耗低。
• 社区活跃，bug和问题能及时修复，还在不断迭代和演化中。
• 使用广泛，有很多成功案例都采用了Netty，质量有保证。

Boost asio 的设计考虑

参考资料

• https://www.boost.org/doc/libs/1_74_0/doc/html/boost_asio
• 拙作：《微服务之道：度量驱动开发》