生在中国这片热土，我们做程序开发的人要面临很多的挑战。只要生命不息，挑战就永远不会停止。
比如最近疯传的 35 岁程序员送外卖。这明显点出了在中国搞开发，要面临的其中之一挑战：年龄。
在整个 IT 领域，大多数的开发者都属于普通人。只有极少数部分人能站在技术的尖端引领技术的前进与走向。那么，普通的开发者，又很容易被新人替换。新人更经济实惠，压力小。而老开发人员技术的天花板无法打破的情况下。要面临跟着一群小朋友一起起早贪黑的工作模式。甚至于会出现自己一把年纪，上面的领导比自己还小好多岁的窘境。
肯定有人会说我们这群老人矫情。但是，又有几人能做到内心毫无波澜呢?
本篇博文主要是针对我们这群普通的开发者处境所写。请允许我在这里贩卖焦虑。
一、系统架构
作为技术这条路线，最终都会偏架构方向。即使做技术经理或总监。都必须对系统架构要有一定的知识储备，以备对团队的架构搭建与变更做出准确的判断。
这里并不是说我们去设计一些千万级别以上 PV 的系统架构。做为普通的开发者，要接触上亿的系统平台相对来说机会并不是很多。即使接触了，也仅仅只是这个平台里面的一个小螺丝。要能主导这个架构的设计，还稍显稚嫩。我再次说明一下，这里仅仅只对普通的开发者。不指那些尖端的高技术人才。
在我的理念当中，千万级别及以下 PV 的构架，通常用不到微服务。所以，不要用微服务来坑自己。加重架构的复杂度。
在这个体系里面有以下技术/服务/文档可能是我们要涉及的：
- 队列服务：Redis、Kafka、RabbitMQ 等消息服务中间件。
- 缓存服务：Redis、Memcache。这里不太推荐 Memcache。
- 多进程/多线程：用来异步处理一些 CPU 数据密集计算的任务或异步处理推送、短信等任务。
- 负载均衡服务：可以采用阿里云成熟的负载均衡服务 SLB 服务。
- 日志存储与分析服务：常听到 ELK 就属于一组组合。不过，我推荐使用阿里云的日志服务。集成了报警功能。这个非常实用。
- 文件存储服务：系统上传的文件不能与业务服务器存放一起。会影响业务服务器的带宽。导致业务访问的数据交互延迟与超时。可以采用阿里云的 OSS。一般千万级别自建这样的存储系统服务，从成本上来说根本不划算。
- CDN 服务：即使我们用了独立的文件夹服务器存储文件。但是，在访问的时候由于用户所处网络不同(电信、移动、联通)，以及区域不同(南方/北方)。所以，CDN 会加快用户访问文件的速度。提升用户体验。
- 数据库：一主多从构架。具体要多少个从数据库根据自己的业务量来设计。通常中小型平台使用阿里云的 RDS 比自建数据库服务更加划算。否则，团队会配备专业的 DBA 来维护数据库服务器。推荐使用阿里云的 RDS 服务。对了。这里说的是MySQL 数据库。其他忽略。
- 监控系统：现如今像阿里云这样的平台，都提供了监控服务。像服务器 CPU、内存使用率告警。数据库资源报警。自建的话，不仅维护需要专人，还可能会导致监控不完善造成的损失。千万 PV 级别不推荐。
- 专用网络 VPC：这个说的是阿里云的 VPC 服务。当然，其他云平台也有。它的核心功能是给自己所有的服务器虚拟一个网络进行管理。避免直接被外网访问，或直接访问外网。说得再直接一点就是避免风险。
像我这样普通的大龄开发者，经历过的大大小小项目也挺多的。要真的能达到千万级别 PV 的挺少的。通常要面临的挑战如下：
QPS：即每秒请求量。通常我们服务器能支持 2000 + 即可。除非做抢购等这种秒杀型的活动，否则很多的 Web 业务根本用不到 2000+。
海量数据：很多时候制约性能的数据库。对海量数据存储就显示很重要。比如，订单分库分表解决。分表解决单表查询性能、分为解决单库性能。
二、网站劫持
网站劫持这是一个比较笼统的叫法。实际有如下几种劫持：
- URL 跳转型劫持：输入 A 域名，强制跳转至 B 域名。
- 注入型劫持。
- DNS 劫持。
而注入型劫持，又分以下几种：
- 注入 JS 类劫持：在正常页面注入 JS 代码实现劫持。常见的就是运营商强制注入广告 JS。
- iframe 类劫持：将正常页面嵌入iframe或者页面增加iframe页面。
- 篡改页面类劫持：正常页面出现多余的劫持网页标签，导致页面整体大小发生变化。
- DNS 劫持：
- 在工作中，经常会有用户跟我们的客服同事反馈 App 打不开或报错。这其中有一部分就是 DNS 被劫持所致。劫持之后 App 请求接口拿不到数据或拿不到指定的数据，肯定会报错。影响用户正常的访问。
- URL 跳转型劫持与注入型劫持都可以通过 HTTPS 方式解决。而 DNS 劫持就比较特殊了。
- 关于 DNS 劫持解决的办法是通过直接访问受信任的 DNS 来解决。因为，这种 DNS 的劫持通常是运营商 Local DNS 缓存问题造成的。比如，攻击者污染了根 DNS 服务器。导致运营商同步造成了数据的污染。自然访问就会出现问题。
所幸，我们可以采用类似阿里云这种平台提供的 HTTPDNS 服务。来解决 DNS 劫持的问题。
HTTPDNS 的功能特性：
- 防劫持:绕过运营商Local DNS，避免域名劫持，让每一次访问都畅通无阻。
- 精准调度:基于访问的来源IP，获得最精准的解析结果，让客户端就近接入业务节点。
- 0ms解析延迟:通过热点域名预解析、缓存DNS解析结果、解析结果懒更新策略等方式实现0解析延迟。
- 快速生效:避免Local DNS不遵循权威TTL，解析结果长时间无法更新的问题。
- 降低解析失败率:有效降低无线场景下解析失败的比率。
- 稳定可靠:99.9%的可用性，确保域名解析服务稳定可靠。
三、系统安全
系统安全真的真的特别重要。作为一名开发老兵，心中始终要有一根弦：代码千万行，安全第一条。
常见安全防范：
- 网络安全：通过专用网络 VPC 把所有的业务服务器进行网络隔离，再采购堡垒机进行服务器管理。
- 密码强度：管理员账号一定要采用 大小写混合且包含数字的 20 位及以上的长度。业务系统用户密码不能为纯数字且长度必须大于8位。同时也要避免连续相同的密码。比如：AAAAAAAA。
- 密码定期更换：不管密码保存得再完美，总会遗漏导致信息泄漏。而定期更换能及时发现并堵住这些漏洞。推荐每 3 个月更换一次。
- SQL 防注入：现在基本上成熟的语言都有一套完整的防注入机制。比如 PHP 语言的 PDO 扩展提供的预处理机制(当然数据库必须支持预处理)。
- XSS(跨站脚本攻击)：XSS 能截获用户的私密网页内容、Cookie 数据。通常是 JavaScript 脚本造成。最好的办法是转文存储。
- CSRF(跨站请求伪造)：危害极大。所有敏感数据的读写操作采用 POST 限制。并且不允许跨域请求。在信息提交时，再做一次令牌的认证限制。
- 文件上传漏洞：主要是避免用户上传恶意的脚本代码获得看我们的权限。解决办法是就严格限制上传文件的后缀。同时把上传的文件放到专业的文件服务器。比如，放到阿里云提供的 OSS 服务器上。
四、代码规范
即使你是外包或建站类型的项目开发，代码规范能帮助你减少项目交叉维护带来的痛苦。
不管是后端 PHP、Java、Go，还是 Web 前端，还是 Android/iOS 客户端。必须有一套代码规范。
PHP 目前通用的代码规范：PSR。
Java 代码规范：目前大多数都会遵循阿里开源出来的一套开发规范。搜索关键词：阿里官方Java代码规范标准。
Go：本身自己都代了一套代码规范。直接遵循语言的规范即可。
Web 前端代码规范：目前网上很多关于这个规范的整理。参照一套即可。
其实代码规范这个东西是一种约定俗成的规定。并不是一层不变的教条。也要因地制宜的形式进行使用。不能生搬硬套。小团队只要大体上没有问题即可。大团队可能就需要专门 Review 代码的机制，以及代码提交的辅助性插件来进行代码规范的验证。
五、工作汇报
如果你是老板可能就不需要进行工作向上汇报。否则，不管是哪个阶层，工作汇报必须是工作中重要的一环。而每个层次的员工汇报工作的方式又有不同的侧重点。
这里指的是工作汇报，而不是项目进度汇报。
(1)非核心开发员工
此类员工工作汇报应该有如下几点：
- 具体做了哪些工作。完成百分比。如：登录注册功能开发。已用时 3 天。进度 80%。
- 遇到哪些问题。工作中遇到了哪些技术难题，自己是否能搞定，如果没搞定是否请求过核心开发或组长级别协助。
- 后续工作计划。这个是让组长以及部门管理者知道接下来应该给你安排什么任务。
(2)核心开发员工
此类员工作为核心输出。与非核心开发员工还是有区别的：
具体完成了哪些工作。
工作遇到的问题。
协助非核心开发做了哪些工作。
后续工作计划。
核心员工重点工作是编写核心业务代码。并且指导并协助非核心开发员工遇到的各种难题。必要的时候，还需要对这此处于最底层梯队的员工进行技术培训。让他们快速成长，慢慢成长为核心员工。
其次，核心员工不但能发现问题，还能解决问题。当需要部门管理者作决策时，是带着A/B决策方案去。
(3)主管级别员工
这一类员工实则是与核心开发员工差不多。在核心开发员工上面进行一层工作的协调分配的工作。
六、职责清晰
这一点是针对开发转技术管理路线的人而言。要让每个开发准确知道自己所负责的事情。说穿了就是职责与责任。
如果职责不清晰，对一些事不关已高高挂起心态的人来说，会导致事情变得难以推进。只有明确职责之后，在事情没有办好的时候，就知道是谁的责任。
七、绩效考核
这个与第六点相呼应。唯一的难点是要能及时且准确对责任做出评估，该扣绩效扣绩效。这奖励的就奖励。绝不能拖泥带水、瞻前顾后。特别是拒绝过分护短的情况发生。
八、上下关系
很多刚从开发转管理的人会有一个毛病。觉得要以技术实力去让人服从。这明显是不合适的。技术能力固然很重要，但不能本末倒置。天下技术千千万。要以这种思维去做技术管理。那我相信，这世界上没有几人能坐得稳。
所以，技术这东西得多去关注理论的东西即要。这样才关键时刻能做出正确的选择。
有些人还觉得要跟下面的人打成一片才能让别人服从自己的工作安排。我并不这样认为。工作中率先不服从或意见最多的反而是那些平常你极力去讨好的人。我们在做管理的时候，只需要秉承公平公正公开的原则，去对待每一个人和工作即可。
那些不愿意服从的人，不管是交好的或关系远的，都应该及时进行制止和批评。如果依然如此，那是他个人问题，不是我们管理的问题。除非我们的工作安排确实出现了严重的不公平不合理的情况。
以上都是自己瞎逼逼的一些总结。
管理这份活儿，它并不容易干。但好在能在此间修休汲取一些实战经验来检验自己的不足。也是有幸之事儿了。
