朱晔的互联网架构实践心得S2E7:漫谈平台架构的工做（基础架构、基础服务、基础平台、基础中间件等等）

前言

程序开发毕竟还不是搬砖这种无脑体力劳动，须要事先有标准，有架构，有设计，绝对不是新公司今天创立，明天就能够开始编码的。其实不少公司在起步的时候没有财力和资源建设独立的基础架构或平台架构部门，甚至运维团队都没有，可是这不妨碍咱们心中有一个蓝图知道努力的方向，本文咱们就简单聊聊平台架构相关的工做内容（或者说做为一个技术管理，应该去梳理、统1、明确的部分）的蓝图。因为本文覆盖的内容比较多，只能抛砖引玉大概提一些，没法一一展开太详细的东西。图中的数字是我认为的优先级，仅供参考。

规范

规范它虽然不是一个实际的代码或组件，只是一个文档，可是我以为很是重要。没有规范，那么员工加下去任何一行新代码可能都是错的，整个研发流程也可能会由于没有规范致使不少没必要要的事故产生。

• 代码提交&分支管理规范，咱们能够在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直接作各类扩展（不须要再麻烦业务团队了）。

咱们来看看这里脑图上大概列出的一些业务开发须要用到的常见模块（能够看一下咱们公司开源的框架SummerFramework（github.com/ke-finance/… ） ，固然开源出来的模块比较少，实际公司内部封装了这里提到的全部模块：

• Web MVC：能够基于Spring MVC进行封装，增长一些模板引擎的支持等
• 数据访问：能够基于MyBatis或Mybatis Plus+Druid数据源进行封装，作一些额外的功能，好比敏感数据加密保存
• RPC服务调用或微服务：能够基于Dubbo或Spring Cloud（Feign+Eureka）进行封装，在客户端方面扩展一些更智能的LB算法，以及路由策略（好比灰度）等功能
• Web API：能够在Spring MVC+Swagger UI基础上实现功能，提供统一的RESTful服务端API的标准，好比规范化API版本、响应结构体自动包装（自适应）、错误包装、HATEOAS超媒体资源导航整合、数据加解密实现、Collection资源的规范化、自动的mock接口的实现等
• 配置：能够基于携程Apollo（github.com/ctripcorp/a… ）客户端进行封装，作自动配置
• 消息：能够封装RabbitMQ、RocketMQ的客户端实现统一的消息API，而后扩展事务消息（收发消息和业务逻辑本地事务在一个事务中处理）等功能
• 缓存：能够基于CacheCloud（github.com/sohutv/cach… ）提供Redis缓存服务
• 调度：能够封装XXLJob（github.com/xuxueli/xxl… ）或ElasticJob（elasticjob.io）提供调度服务
• 日志监控：能够基于Micrometer实现应用打点，找一个APM（Skywalking github.com/apache/skyw… 或Pinpoint github.com/naver/pinpo… ）整合trace功能，扩展logback作日志脱敏，扩展Spring Boot Actuator Endpoint等功能
• 锁：能够基于Redisson封装分布式锁，使用统一的API来提供内存锁和分布式锁
• 分布式事务：主要是两块，同步2PC分布式事务处理（好比咱们开源的https://github.com/ke-finance/dts ），异步的saga思想的实现，参考https://github.com/eventuate-tram/eventuate-tram-sagas 。
• 弹性：流控+隔离+熔断，考虑基于https://github.com/alibaba/Sentinel 来实现，能够是独立的模块提供服务，也能够整合到Web API或RPC模块中去
• 安全：能够基于Spring Security进行扩展，加入符合业务需求的风控策略进去

基础平台

基础平台（管理平台）须要和基础框架打配合，框架是开发的时候使用的，平台更多的是开发或运维人员作技术运营时使用的。不少开源框架都已经提供了管理后台，咱们须要作的可能只是一些小修改，好比包括：

• 打通公司内部本身的帐号登陆体系和权限体系
• 根据不一样的环境（开发、测试、灰度、生产）部署多份管理控制台
• 根据须要看是否须要作多租户的改造，实现业务隔离

有些平台是重流程的，这些可能须要自主开发，大概介绍一下脑图上提到的这些：

• 配置平台：若是使用了携程Apollo，天然就是使用Apollo的管理后台
• 微服务管理平台：这里我列出了两个方面的工做，一个是服务中心，更多的是服务维护、管理、监控方面的功能，能够基于Spring Cloud Admin进行改造；一个是服务集市，更多的是服务标准化方面的管理，好比服务上线须要的文档，接入的监控系统，以及上线后统一的文档中心，服务集市相似于App Store的概念
• 缓存平台，若是使用了CacheCloud，可使用CacheCloud的管理后台
• 日志平台，分为两块，一块是日志收集展现基本ELK已是标准；还有一块是日志异常报警，能够本身来开发，基于Kafka消费日志异步作日志筛选+聚合结合本身公司的IM和邮件体系作报警
• 数据库管理平台：
  • DDL/DML工做流：开发提交申请，主管审批，自动执行，外加自动的风险检测，优化建议等
  • DDL/DML变动通知：方便大数据以及运营团队针对感兴趣的数据库和表进行订阅，在DDL应用到各个环境（测试、生产）的时候可以第一时间获得通知能够进行人工、自动处理（相似before，after Filter的概念）
  • 数据库知识库：有一个统一的地方查看数据库的结构说明、字典枚举的定义
  • 固然数据库管理平台还能够进一步作数据库监控、慢SQL优化缘由分析等功能
• 全链路追踪平台：好比若是使用Skywalking的话能够实现它提供的管理台，主要功能无非是依赖拓扑分析、Trace查看、服务性能分析等
• 指标查看平台：分为两块，Dashboard通常能够考虑直接使用Grafana，报警的话虽然Grafana也有Alert可是仍是建议在更底层（数据源头）去作，能够基于流处理去作或基于定时拉的方式去实现

基础中间件

中间件是指独立部署的不具备业务逻辑耦合 的通用服务，存储服务在广义上归到中间件也不是不能够，这里大概列了几个典型：

• MQ代理（Broker，不是Proxy），好比RabbitMQ、RocketMQ、Kafka
• API网关，有不少开源的网关实现，好比Kong（github.com/Kong/kong ）、Spring Cloud Gateway，咱们也实现了一套https://github.com/ke-finance/tesla ，通常网关的主要功能是调用路由、协议转换、调用编排，而后也会以插件和过滤器形式提供不少安全、弹性方面的扩展功能
• DB代理，好比相似https://github.com/flike/kingshard 和https://github.com/Qihoo360/Atlas 的MySQL Proxy，实现数据库的读写分离、分表分库、故障转移、弹性处理、监控、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个内部系统是和研发相关的，甚至须要有专门的导航网站来管理工程效率、运维、基础框架、基础服务、基础中间件、基础平台的这些网站，这些系统自己的维护工做量也是不小的，一整理就会发现原来除了业务程序还有这么多周边的东西是为研发服务的，欢迎你们针对本文的内容进行补充。