统一开发技术
统一开发技术
前言
程序开发毕竟还不是搬砖这种无脑体力劳动，需要事先有标准，有架构，有设计，绝对不是新公司今天创立，明天就可以开始编码的。其实很多公司在起步的时候没有财力和资源建设独立的基础架构或平台架构部门，甚至运维团队都没有，但是这不妨碍我们心中有一个蓝图知道努力的方向，本文我们就简单聊聊平台架构相关的工作内容（或者说作为一个技术管理，应该去梳理、统一、明确的部分）的蓝图。由于本文覆盖的内容比较多，只能抛砖引玉大概提一些，无法一一展开太详细的东西。图中的数字是我认为的优先级，仅供参考。
规范
规范它虽然不是一个实际的代码或组件，只是一个文档，但是我觉得非常重要。没有规范，那么员工加下去任何一行新代码可能都是错的，整个研发流程也可能会因为没有规范导致很多不必要的事故产生。
- 代码提交&分支管理规范，我们可以在gitflow基础上根据实际情况（结合运维流程，项目复杂度，团队人数，发布周期）进行细化，涉及到：
- 有哪几个常驻分支，哪几个临时分支？
- 分支命名规范？
- 提交代码描述规范？
- 分支迁出和合并的时机？
- 哪些分支普通开发没有权限直接提交？
- 测试用什么分支，上线又用什么分支？
- 多版本并行开发如何提测？
- Hotfix如何处理分支？
- 编码规范，比如Java代码可以以阿里Java开发手册为基础，大家一起过一遍，针对项目的实际情况（时间要求，对性能要求），选择其中的一些坚决执行，然后补充一些其它的。我们也可以让大家的IDE使用（导入）统一的Code Style Template来要求一致的编码格式。因为Code Style的不一致导致提交的时候大范围的代码新增删除完全会污染提交，让大家很难看出提交的代码到底改了什么。
- 数据库设计规范。阿里Java开发手册里包含了一小部分数据库设计规范，术业有专攻，这个还是应该请资深DBA来给出一定的规范，包括但不限于：
- 命名（表和字段前缀后缀命名，外键字段命名、通用字段命名统一）规范
- 字段设计类型规范
- 字段冗余规范
- 通用字段规范
- 索引使用规范
- ……。可以参考《朱晔的互联网架构实践心得S2E1：业务代码究竟难不难写？》中提到的一些内容
- 项目结构规范，对于Java Maven项目来说基本目录结构比较统一，对于其它语言的项目（比如Python），目录结构没有一定标准的话，项目源码结构会千奇百怪，最好还是对于项目结构有一个规范，包括：
- 三层结构目录划分
- 多环境（Profile）配置文件
- 服务接口、服务实现、Web、Job模块命名
- 最后是项目管理流程，有一些公司会有专门的PMO，有一些初创公司研发Leader也会充当PMO的角色，虽然这个活一般和平台架构没啥关系，不管怎么样，既然是项目肯定少不了项目管理，作为技术管理角色需要关注的一个点，项目管理流程也是比较重要的：
- 迭代周期，迭代周期中的大环节大概发生的时间点
- 开哪些会，开会时间点是？（日站会、周例会、启动会、回顾会、复盘会、排期会、PRD预评审会、PRD评审会、测试用例评审会、上线方案讨论会）
- 项目生命周期中每一个角色产出哪些文档？
- 任务在哪里管理，每一个角色怎么去维护任务状态的流转？不可能任务的每一个状态的流转都由PMO来做
基础框架
使用一些基础框架来做应用开发是必须的，对于Java技术栈，大家所熟悉的框架有Spring Cloud全家桶、Spring Boot套件（封装的各种starters）、Mybatis等，直接使用这些框架进行开发是可以的，但是更建议的是由基础架构团队封装自己的框架，自己做一层封装，我们可以以类似Spring Boot Starter的模式，为所有的组件封装自己的Starter模块，好处是：
- 方便进行统一的外部依赖类库 & 库版本管理和约定
- 方便针对公司内部情况做更合适的自动配置（甚至实现0配置）
- 如果内部技术栈是异构的话，使用统一的框架有助于技术栈后端基础设施的打通
- 为所有的模块打通监控，自动配置AOP做相应的拦截统一抓取获取监控数据
- 模块之间可以相互整合和配合，实现1+1>2的效果
- 还有很重要的一点是，我们可以提供相应的管控后台来配合框架使用，把框架的配置、管理和审计暴露在控制台上
其实说白了，就是使用自己封装的类库占坑，哪怕只是一层浅浅的封装，也是很有好处的，不仅仅是做了各种统一（使用框架的统一，框架版本号的统一），更多的是因为占了坑（当然，要扩展做Java agent动态字节码注入的方式也是可行的，这种方式的缺点是没有办法提供API给业务使用），以后直接可以通过升级框架通过IOC组件替换+AOP直接做各种扩展（不需要再麻烦业务团队了）。
- Web MVC：可以基于Spring MVC进行封装，增加一些模板引擎的支持等
- 数据访问：可以基于Mybatis Plus+Druid数据源进行封装，做一些额外的功能，比如敏感数据加密保存
- RPC服务调用或微服务：可以基于RESETemplate或Feign进行封装，在客户端方面扩展一些更智能的LB算法，以及路由策略（比如灰度）等功能
- Web API：可以在Spring MVC+Swagger UI基础上实现功能，提供统一的RESTful服务端API的标准，比如规范化API版本、响应结构体自动包装（自适应）、错误包装、HATEOAS超媒体资源导航整合、数据加解密实现、Collection资源的规范化、自动的mock接口的实现等
- 配置：可以基于Consul客户端进行封装，做自动配置
- 消息：可以封装RabbitMQ或Redis实现统一的消息API，然后扩展事务消息（收发消息和业务逻辑本地事务在一个事务中处理）等功能
- 缓存：可以提供EHCache或Redis缓存服务
- 调度：可以封装XXLJob或ElasticJob
- 日志监控：可以基于Micrometer实现应用打点，扩展logback做日志脱敏，扩展Spring Boot Actuator Endpoint等功能
- 锁：可以基于Redisson封装分布式锁，使用统一的API来提供内存锁和分布式锁
- 分布式事务：主要是两块，同步2PC分布式事务处理和异步的saga思想的实现
- 弹性：流控+隔离+熔断，考虑基于https://github.com/alibaba/Sentinel 来实现
- 安全：可以基于Spring Security进行扩展，加入符合业务需求的风控策略进去
基础平台
基础平台（管理平台）需要和基础框架打配合，框架是开发的时候使用的，平台更多的是开发或运维人员做技术运营时使用的。很多开源框架都已经提供了管理后台，我们需要做的可能只是一些小修改，比如包括：
- 打通公司内部自己的账号登录体系和权限体系
- 根据不同的环境（开发、测试、灰度、生产）部署多份管理控制台
- 根据需要看是否需要做多租户的改造，实现业务隔离
有些平台是重流程的，这些可能需要自主开发，大概介绍一下脑图上提到的这些：
- 配置平台：需要在consul基础上开发配置操作界面。
- 微服务管理平台：一个是服务中心，更多的是服务维护、管理、监控方面的功能，可以基于Spring Cloud Admin进行改造；一个是服务集市，更多的是服务标准化方面的管理，比如服务上线需要的文档，接入的监控系统，以及上线后统一的文档中心，服务集市类似于App Store的概念
- 缓存平台：需要可以管理Redis和应用中缓存
- 日志平台：分为两块，一块是日志收集展示基本ELK已经是标准；还有一块是日志异常报警，可以自己来开发，基于Kafka消费日志异步做日志筛选+聚合结合自己公司的IM和邮件体系做报警
- 数据库管理平台：
- DDL/DML工作流：开发提交申请，主管审批，自动执行，外加自动的风险检测，优化建议等
- DDL/DML变更通知：方便大数据以及运营团队针对感兴趣的数据库和表进行订阅，在DDL应用到各个环境（测试、生产）的时候能够第一时间得到通知可以进行人工、自动处理（类似before，after Filter的概念）
- 数据库知识库：有一个统一的地方查看数据库的结构说明、字典枚举的定义
- 当然数据库管理平台还可以进一步做数据库监控、慢SQL优化原因分析等功能
- 全链路追踪平台：使用ZipKin可以实现依赖拓扑分析、Trace查看、服务性能分析等
- 指标查看平台：分为两块，Dashboard一般可以考虑直接使用Grafana，报警的话虽然Grafana也有Alert但是还是建议在更底层（数据源头）去做，可以基于流处理去做或基于定时拉的方式去实现
基础中间件
中间件是指独立部署的不具有业务逻辑耦合 的通用服务，存储服务在广义上归到中间件也不是不可以，这里大概列了几个典型：
- MQ代理（Broker，不是Proxy），比如RabbitMQ、Kafka
- API网关，基于开源的Spring Cloud Gateway网关实现，一般网关的主要功能是调用路由、协议转换、调用编排，然后也会以插件和过滤器形式提供很多安全、弹性方面的扩展功能
- DB代理，实现数据库的读写分离、分表分库、故障转移、弹性处理、监控、SQL优化等功能
- ES集群，也可以理解为中间件，毕竟ES其实做的就是基于Lucene的分布式集群管理工作
这些中间件虽然很多时候做的是Proxy背后的其它服务，但是节点本身很可能是有状态的，也需要考虑中间件本身的高可用性问题。
基础服务
一般而言如果公司具有多个项目的话，项目之间肯定会用到一些通用的内部和外部能力，这些能力和业务逻辑没有太多关系，可以考虑把这些能力进行统一的封装独立部署以微服务形式提供出来，这样所有项目都可以快速对接。
在这里把基础服务分为了两类，一类是没有业务逻辑的纯基础服务，往往是对接封装一个或多个外部服务通道，另外一类是包含一些业务的业务基础服务。对于第一类基础服务你可能会想，既然是对接外部服务通道直接使用他们的SDK或服务是不是直接在业务系统使用那些三方SDK就好了，基础服务是需要做什么呢？我觉得基础服务应该这么封装：
- 封装外部服务的SDK，一般而言比如短信也好、推送也好、存储也好，都会使用多家提供的服务做备份、降级，通过我们的SDK提供统一的对内API，屏蔽不同SDK的API差异
- 提供一个服务端，在服务端做数据落地，落地的目的有几个：
- 方便和外部进行服务消费对账
- 方便出错的时候查找原因
- 方便和外部服务同步调用状态（比如短信到达）
- 方便进行服务余额预警
- 服务端除了做数据落地，由统一的服务端做出口的好处是：
- 做权限控制，一般而言即使是公司内部的项目进行基础服务的调用应该也是需要先申请再使用的，甚至需要做服务调用量的控制（类似在内部再实现一层SaaS）
- 收敛调用源IP
- 集中管理调用外部SaaS服务的密钥
- 外部服务的降级和切换策略更换比较方便
- 给接入方做报警
- 做一个管理后台，虽然外部服务提供方作为SaaS产品一般都会有不错的控制台（其实更多的时候，不可能把外部服务的控制台的权限放给所有人看，内部业务方看自己的基础服务控制台即可），但是我们内部做一个管理后台意义还是很大的，主要的功能一般是：
- 统一登录
- 账号（包括Secret）申请和分配，以及配额、限流等配置（管理员权限）
- 调用记录（请求、结果）查看
- 调用模板的配置（考虑一下是不是放开服务的使用，比如短信、邮件、推送一般是基于模板的，模板需要内部外部审核后才能使用）
如果每一个服务都有控制台的话，可以大大方便业务方的自主接入和问题排查，这是基础服务封装非常有价值的一个点，对于大点的公司内部项目众多就更需要把基础服务在内部进行SaaS化了，而且最好对于不同的基础服务打通接入方（统一的地方来申请所有需要的基础服务）。
这里脑图上大概列了一些常见的基础服务和业务服务，每一个公司根据自己的业务一般都会不尽相同，基础服务包括：
- 短信：接入多个短信渠道，根据政策、费率、到达率等情况路由
- 文件存储：接入多个小文件存储服务（比如七牛、腾讯云），根据存储服务提供的功能，文件大小、费率等情况路由
- 邮件：接入内部和外部（比如SendCloud）的邮件服务，根据使用场景进行路由
- 推送：接入多个推送渠道（比如极光、个推），并且做用户、设备的关系维护
- 唯一ID：全局唯一ID的生成
- 图形、滑动、点击、智能验证码：提供统一的验证码服务，可以根据场景自动选择验证码类型
- 电子签章：接入多个电子签章服务，根据费率等因素路由
- 地图服务：接入多个外部地图服务，根据功能以及接入方使用的地图进行服务选择
业务服务包括：
- RBAC权限控制：统一的RBAC配置后台，以及方便的SDK
- 通用表单服务：根据后台配置的表单自动生成界面，以及表单信息的收集
- 状态机：可以借鉴https://github.com/hekailiang/squirrel ，基于状态(State)、行为(Action)、转移(Transition)、条件(Condition)等概念，构建基于数据库的状态机平台
- 统一支付：聚合支付，业务方可以快速接入多种支付渠道，并且统一支付可以提供统一的SDK和H5来实现统一的支付收银台
- 工作流、爬虫、SSO……不详细说明了
工程效率
接下去也简单提一下工程效率和运维范畴的事情，虽然这和平台架构没啥太大关系，但是这两块是很重要的技术基建工作：
- 源代码仓库：比如可以选择Gitlab或atlassian三件套的Bitbucket
- 内部类库仓库：比如Java的Maven仓库，可以自己搭建Nexus仓库
- 项目管理平台：可以选择SaaS产品（比如Tower、Teambition），比较有名的是atlassian三件套的Jira
- 知识管理平台：可以选择SaaS或开源Wiki产品，比较有名的是atlassian三件套的Confluence
- Bug管理平台：比如可以选择禅道或直接复用Jira
- 代码质量分析：比如可以搭建SonarQube平台
运维
这里提到的一些运维系统相关工作有的公司是架构团队来建设的，列一个大概：
- CI/CD平台：一般而言需要自己结合公司的工作流程做一套CI/CD平台（底层可以基于Jenkins（或直接SSH+脚本）封装），这个平台需要结合公司的工作流程去做，比如谁可以发起流程，每一个发布环节需要谁来审批，发布时间窗口等等
- DNS平台：一般会直接使用域名管理商的平台或类似DNSPod这种平台
- CMDB：一般都会根据自己的情况自建平台，进行运维各个层次相关资源的元数据以及配置管理
- 监控：一般会基于Prometheus+Grafana+Zabbix等开源项目来打造运维的基础监控
- CDN平台：一般是用云的，比如七牛、又拍或三大云服务的CDN都可以
- 集群配置管理：这个不是指CMDB，是指批量进行集群配置应用操作，管理操作的平台，比如Chef、Puppet、Ansible、Fabric，一般也是基于开源改造封装或直接用开源的
- 容器编排：比如K8S平台，一般可能会基于k8s的API做一套自己的k8s管控平台或选用类似Rancher这种更好用更高层的服务，完全基于命令行的k8s运维不是很高效易用
- 容器镜像仓库：比如Docker私有仓库Harbor
总结
好吧，的确一些中大型互联网公司是有超过100个内部系统是和研发相关的，甚至需要有专门的导航网站来管理工程效率、运维、基础框架、基础服务、基础中间件、基础平台的这些网站，这些系统本身的维护工作量也是不小的，一整理就会发现原来除了业务程序还有这么多周边的东西是为研发服务的，欢迎大家针对本文的内容进行补充。
图书出版
整个流程主要分为三个阶段，即选题阶段、写作阶段和编排校印阶段。
- 选题阶段：需要你填写选题表、大纲和样章，待我们收到这3个文件后，会内部讨论选题的可行性，若可行（一周内会回复结果），就开始签约稿合同并申报选题，待选题通过后，开始签出版合同。
- 写作阶段：一般要求作者在约定交稿时间的1/4、2/4、3/4时进行阶段回稿。阶段回稿的目的很明确，一是及时跟踪稿件的进度和质量，二是及时给作者修改和反馈意见。一般情况下，收到阶段回稿的稿件后，编辑会在10个工作日内给出反馈意见。
- 编排校印阶段：待作者交稿后，我们先进行初审，初审通过后开始编辑加工，然后进行复审、三审和发稿的流程，接着进行三排三校、出片和印刷等流程。如果稿子没有什么大问题，交稿后三四个月即可出版。
图书稿酬说明
-
关于作者稿酬（指的是税前稿酬，其中个人所得税应由出版社代扣代缴），通常采用版税方式支付：
作者稿酬 = 图书定价 × 版税率 × 实际销售册数
比如，定价为50的书，版税为8%，实际销售册数是1万册，作者拿到的稿酬就是 508%10000=40000元。
-
出版社会在作品出版后60天内向作者支付稿酬。
章节层次
可参照下列示例格式，可越层使用。正文中引用章节时一般采用“见第3章”、“见3.1节”、“见3.2.1节”的形式，不要出现相应的章名和节名。
- 一级标题：第1章 计算机图形学概述
- 二级标题：1.5 计算机图形硬件和软件的发展
- 三级标题：1.5.1 输出技术
- 四级标题：1. 输出技术
此外，需要说明的是，步骤号用(1)、(2)、(3)、(4)和(5)表示（注意数字外面的括号是半角的）。
代码书写规范
- 整段代码用Courier New字体，8磅字。
- 写代码时注意代码的缩进问题，要求缩进4个字母。
- 若非必要情况，应在程序编写环境中编写代码，然后原样复制到书稿中。
- 书中的代码段有两种，一个是比较短的代码，一个是比较长的需要读者从网上下载的代码，其中后者均需按章编号（比如代码清单1-1）。对于比较长的代码，首先在正文中说明该代码的作用，然后给出代码并加上代码清单的标题（该标题后面不加标点）。
- 关于全书的源代码，除了在GitHub上提供外，还需要提供一个可以让读者下载的压缩包以供我们放在社区。
图片规范要求
- 书中所有的图均需按章顺序编号（比如图1-1和图1-2等），图题和图字后均都不加标点符号，图号和图题之间空一个字的空（即半角状态下的两个空格）。
- 抓取屏幕图时需要注意：
- 计算机屏幕图使用一般抓屏软件即可。分辨率根据软件默认即可。只要打印出来清楚，即能达到印刷效果。
- 存储格式一定要存为TIF或者JPG格式。图片大小不用做调整。一般在Word里缩放即可。
- 对于流程图和框图，最好在viso或者PPT中绘制，以方便后期编辑加工。 说明：图中的图字是可编辑的，中文字号和字体分别为8磅、汉仪书宋一简，英文字体为Times New Roman。另外，如果会用AI或者CorelDRAW绘图，最好用这两个软件画，别的软件做的图排版还得重新做。
- 若要在图片上添加文字，建议在Word中使用文本框或者标注添加，而不要使用图片编辑器加字，以免损失图片质量。
- 针对书中的图片和小图标，我们有如下要求：
- 将书中每章的图片分别放在一个文件夹中，并按照图号命名，以便将来排版导入。
- 如果正文中大量用到工具栏或对话框中的小图标，请把每章的小图标单独存为一个文件夹，小图标的名称按书中所提到的名称为准。
- 截图上面的文字不要有错误。截图时一定要认真过一遍图片上的文字，以免后期重复截图。
- 截取之前尽量调小对象窗口，使之突出显示出所要表现的部分。截图之前一定要对屏幕上的所有元素进行合理布局，最低要求是主要目的表达突出，其他无关内容不必出现在屏幕上（例如输入法状态栏、某个按钮的提示框、部分其他窗口等）。
表格
稿件中的表格，除特殊情况外，一律使用全线表。表应有表号和表题，表题最后不加标点，表题和表号之间空一个字的空。全书的表号按章编号，如第1章第一个表，可写成“表1-1”，附录中的表可写成表A-1。注意：表中各项内容结尾处均不加标点。
其他写作注意事项
- 不得大量抄袭和复制其他人的著作内容（包括翻译国外的文档、网站、图书等），版权无小事。
- 写作时要注意“敏感”问题，书稿中不能出现新华社《新闻报道禁用词汇》出炉的禁用词。
- 关于书中的地图，如果需要用中国地图，可以从国家测绘地理信息局的网站下载，详见http://bzdt.ch.mnr.gov.cn/。
- 注意图片的版权问题，如果不是作者原创的图片，请确认不涉及版权侵权或者经过合法授权。
- 术语应准确、规范并全书统一，多个作者时更要注意。
- 注意英文的大小写，应严格规范英文的大小写和单复数，如Windows不应用windows。
- 中文和英文之间没有空格。