背景
时间回到2017年底，那会儿SpringCloud正处于如火如荼的状态，加上与K8s的完美契合，整个互联网公司也想借着这波热度做一次真真正正转型，但真正能落地有经验的人少之甚少，大部分公司还是摸着石头过河，不清楚一个完整的体系中到底需要包含哪些东西，我有幸负责了从零到一建设，见证了从一到一百的过程，下面我讲带你揭开什么是企业级SpringCloud微服务架构吧，就俩字“真™香”。
前言
如果您正在筹备如何搭建电商领域的业务中台，还在烦恼技术如何选型，那么这篇文章看完保你治百病，如果你只是想随便看看，那拿好小本本记好吧，这篇文章干货实在太多了。
你说中台过时了？其实这就是个名词，没什么过不过时这么一说，我在2012年就开始做类似的事情，只不过当时也没啥好的代言词，那会儿在流行的是SOA架构，出去跟人说我在做ESB个个觉得这个厉害，虽然两者间理念不一样，但是从设计思路上来看完全一致，SaaS化的模型，多租户的体系，归根结底就是要高度抽象复用。这种架构我这一做就是小10年，一直在To B的领域长期奋战，期间也做过To C的产品，但总觉得不来电，或许这就是To C与To B的区别，两者间的复杂度并不在一个方向，你要硬让我说哪个更复杂，我会选To B，因为要求广度更深，你才能抽象出更快速能交付给前台可使用的能力，灵活配置成为了To B重中之重，当然并不是说To C不复杂，我认为他们不在一个维度，有着多入口大流量的To C产品，你要设计的绝对是极简好用架构。
接下来说说我用这个架构承载了什么样的业务，搭建的初期压根也没想着搞什么中台，那会儿公司的生意是做各个头部品牌电商，当时的玩法是给每个品牌独立部署属于他们网站，代码也是从一套基线中复制粘贴，这种做法并不是完全不可行，其实大部分公司现在还是这个套路，但它的弊端你是也绝对不能忽视的，例如新增的特性如何应用于已经交付的品牌中，再例如基线中代码存在缺陷怎么快速修复应用，这些看似简单的问题当你真正身处在其中，你会发现最后不是写代码那么简单的事情，牵扯到一系列的协调和事务性工作，大大降低了对外的交付效率，所以我们下定决心去做一次转型，希望能通过一种中心化微服务的方式，让交付团队更专注于交付的本身，从而降低企业研发成本。至于能提供什么样的能力，这完全取决于你的公司是做什么生意的，比如做电商要提供商品、订单、促销、内容等能力，比如做教育要提供教务、培训、课程等能力，但是你发现这些能力还是业务产品导向，其实与架构本身没直接关系，所以基于一套标准的微服务架构建设体系可以在在任何领域。
正文
废话不多说，先上一张精心打磨的架构图，喜欢的可以去ProcessOn观摩（我可不是打广告，毕竟国内除了它也没啥好用的在线绘图工具）戳我去看
接下来我会对着这张架构图去剖析每个板块承载的职责
微服务
微服务是一种用于构建应用的架构方案。微服务架构有别于更为传统的单体式方案，可将应用拆分成多个核心功能。每个功能都被称为一项服务，可以单独构建和部署，这意味着各项服务在工作（和出现故障）时不会相互影响。
想把研发团队做强做大，我还真想不出来有什么架构比微服务更合适不过了，想想如果几个人维护个单体应用还是搞定的，但是随着公司规模扩展，业务增长井喷，带来的就是要扩招产研团队，那么相对独立工程搭建方式就成了最佳实践，下面我会讲讲沉淀出的一些标准领域服务，这些服务可能适用于各行各业，各个领域。
业务型
-
订单领域，全渠道订单整合，从传统零售到新零售在到跨境电商，任何行业多少都会与订单相关，做为业务中台最核心领域，设计出漂亮的统一订单服务至关重要
-
商品领域，全渠道商品信息管理，为收集、管理和丰富商品信息，并将其分发到任何的电商销售渠道，让运营团队上新产品的交付更快速，更便捷
-
营销领域，促销、卡券、大转盘、拆红包，但凡你们公司的产品需要拉新还是复购，做营销就少不了它
-
内容领域，企业建站，SEO，页面的动态配置，数字资产维护，几乎每个公司都会需要
引擎型
-
支付引擎，聚合支付网关，屏蔽业务与支付渠道挨个对接的痛点，真正做到一次接入全渠道打通，而且这个产品无关公司属性，可以一直扩充渠道
-
消息引擎，基于事件驱动消息的发送，封装各类通道如SMS、Email、Push、Callback、Webhook等，通过事件配置化选择通道发送
-
搜索引擎，在Elasticsearch、Solr之上包装的一层通用服务，屏蔽由中间件升级更新带来的服务被动升级，弱化查询语句，对外统一标准，适用于全文检索、海量订单多维查询、业务型日志场景
技术型
-
文件服务，提供统一文件上传下载，导入导出能力，让业务无需关系存储介质的实现，集中化处理任何与文件相关功能
-
元数据服务，提供数字字典，系统变量，主数据存储能力，与业务无关
-
调度服务，定时任务处理，开源产品XXL-JOB、ELASTIC-JOB都很好用，当然自研也是个不错的选择，前提是别重复造轮子
服务治理
配置中心 Apollo
如果你想要做All in one制品发布，没有配置中心配置管理起来可非常麻烦，我举个例子，假设你将服务的全环境配置都打进了制品中，突然在上线的当天说有个配置要修改一下，这个时候可想而知，你需要重新打包制品，而这个重新打包制品的环节，没有人能保证两次制品的Gap只是配置的变更，所以我们需要将程序与配置隔离，从而做到All in one输出能力最大化。
不是讲SpringCloud架构吗，为啥不用Spring Cloud Config，还是那句话Spring给你提供是最基础的特性，如果想投产使用往往都需要加工，就拿Spring Cloud Config来举例，配置的维护要是要借助Repository来完成，这在工程实践中是不可想象的事，最后还是要研发出一款专门为配置做的可视化工具，所以像Apollo这种开箱即用的产品还是非常好用。
注册中心 Eureka
这不都闭源了吗为什么还要用，确实注册中心产品一大把Zookeeper、Consul、Nacos想用哪个都可以，不过我们围绕着Eureka做了新特性，比如灰度发布，多租户隔离，通过Metadata注入的方式，标记着每个服务的用途，配合着SpringBootAdmin可以在线控制每个服务允许接收的流量请求，其实对于注册中心来说，能做到服务发现和服务注册的功能也就差不多了，从治理的角度来看，要明确每个角色的职责。
中间件
RDS类的选型如果在非自建IDC的情况下，尽可能选用云服务，像Mysql、Redis、MongoDB这些产品云服务都提供了完整的生态，无论是扩展性、可用性、稳定性来说都要比自建来的更实惠，不然你就要斥巨资让DBA维护着这些产品，坦率讲自建真的能做到跟云产品媲美吗，这里要打上个问号。
非RDS类产品尽可能还是自建吧，比如K8s、RocketMQ、Elasticsearch这些产品牵扯到云供应商的切换风险，一旦哪天你老板心血来潮说我们从阿里云换成AWS吧，那你可真得掂量掂量换得来不。
中间件在微服务架构中扮演着非常重要的角色，搭建时一定要保证这些产品的高可用性与集群扩展能力，可不能搞个单机版当游戏玩，我的经验来看中间件搭建不当发生的事故概率是非常高的
日志分析
日志是用时方恨少，我想这是每个工程师的心声，如果你的公司看日志还通过登录到服务器，或者由运维工程师线下私信给你，那你可能要想想是不是换成在线日志平台了，毕竟基于Elasticsearch引擎，搜索的姿势可以变换自由，想搜啥就搜啥，而且 ELK 也不仅仅局限于日志领域，也可以通过Alert组件来实现业务保障特性，例如服务提前埋好点，对于一些业务的例外错误，可以收集起来提前预警，第一时间通知运营及产研团队。
Monitor
完备的监控体系是在微服务架构下不可或缺的环节，我们可以通过不同维度的监控，从而大幅度提升服务的稳定性。
服务监控
这里使用SpringBootAdmin，它可以实时检查服务健康程度与内存和CPU指标，动态查看HttpTrace与线程使用情况，而外附加轻量日志查询功能
K8s集群监控
这里使用Prometheus，第一时间获取Pod超阈值报警，这与服务监控维度不同，更多的是来检测系统级故障
An open-source monitoring system with a dimensional data model, flexible query language, efficient time series database and modern alerting approach.
主机监控
如果有自建机房，你可选用 Zabbix，如果是用云服务，那就用自带的监控吧，绝对不差事
监控可视化
少了 Grafana 可不行，不然你连装B投大屏的机会都没了，把Prometheus实时检测的数据做几个Dashboard搞个75存大电视一投，那逼格一下子就上来了，安利老板的利器。
全链路监控
这里我会选用 Pinpoint，你可能会说Skywalking不比这好多了，如果你不是深度用户，随便看几篇对比的文章就下定论那太草率了，Skywalking支持的监控插件确实多，社区也很丰富，Agent性能确实比Pinpoint要强，但这些往往不是我们最迫切需要的，我们用全链路监控的目的是能看得清调用链路中存在的潜伏问题，需要的详细Trace，作为架构师或Director的你，总不能在服务性能出了问题的时候跑到工程师电脑前Debug吧，我们需要用工具提供尽可能的帮助，来让工程师有自主解决问题的能力，我宁愿牺牲些性能来换取更强有力的工程实践，或许这也就是To C与To B产品的侧重点不同之处吧。
DevOps
微服务就必须要结合DevOps？不结合你还敢说你微服务架构精通，我看你连门还都没入，还跟我扯精通。微服务的精髓亦是与DevOps紧密结合，如果把服务看作产品交付物，DevOps就是车间流水线，保证的是你每次产品迭代升级不出错，可以更快速更持续的交付出高质量产品，如果你发布的服务都是一次性的那就当我没说，不过我还没见过哪个公司产品那么牛b，迭代都不用的。
没听过DevOps，CI CD总听过吧，啥，这也没听过？别着急，这其实就是个名词，你公司指定早就在做了，只是没那么标准罢了，或者说没做到某种程度。
DevOps这词儿早在10年前就有了，只不过都是歪果仁提出的，当时迷迷糊糊的也确实不知道是干啥用的，上张图你一看就明白了。
切，我们公司就是这样做的啊，开发，测试，运维相辅相成，配合的相当默契。我猜你说的应该是通过即时通讯配合的默契吧，这种协作性不排除在一些规模不大的公司确实很默契，想过研发团队几百号人，服务成百上千时的情形吗？那一定是小马拉大车，再好的发动机也会被累死。
我们需要做的是让它自动化，智能化，数字化。
- 啥是自动化？让你连构建按钮都不要点，Push代码到仓库后，通过webhook自动触发流水线作业，构建过程参数化，不需要人工干预，自主驱动Jira Task
- 啥是智能化？贯穿研发，测试，运维，加速发布周期，监控发布成功率，实时反馈结果，确保软件交付质量
- 啥是数字化？将代码贡献量，质量率，bug数，构建的成功失败率，hotfix频率结合在一个窗口下展示，数据真正的价值一目了然，这里就不展开讲了
想想以前发布个新项目要多久，10分钟，半小时，还是1天？我怕你一礼拜都搞不定，为啥，上新服务时Ops工程师会问“端口号是啥”，“域名是啥”，“配置配好了吗”，“要部署几个节点啊”，“是tomcat部署吗”，一大堆乱七八糟的问题扑面而来，好不容易你都弄明白了，Ops工程师给你来句“唉，你端口号和别的项目冲突了，换成这个吧”，我去™的那你问我干嘛。这种无意义的内耗加剧了企业交付的难度，原本很简单的事情变得复杂化，原因归根结底都是跟“人”有关系 这也就是为什么我们需要通过DevOps来解决工程实践中交付难的重要意义，未来国内研发的时代一定会向Facebook、Google看齐，变成人人自驱、来去自由的时代，阿里的云效就是在将软件工程推向另外一个高度。
概念听完了那再来说说什么是CI（持续集成）CD（持续交付），这是真正落地的产物，通过两个核心的平台来支撑整个流程
自动化运维平台
你首先得知道这个平台到底能干啥？简单说构建发布，复杂说你得保证构建和发布的结果不能有问题，那我们是怎么搭建这个平台的？
首先一些产研用到的工具都得先准备好，比如Jira、Confluence、Gitlab、Nexus、YApi（接口文档平台）、Yearing（SQL工单平台）等，有了这些产研团队就可以开始干活了。
然后要开始准备构建与发布用到的工具，比如Jenkins、Kuboard（K8s集群管理工具）、Harbor、Sonarqube等，这些准备好了基本上就可以做第一版的CI/CD流程了，这里我要重点强调所有与运维相关脚本一定要放在代码仓库中管理起来。
框架搭建完毕后，剩下的就是在每个需要用到的地方塞东西里，比如你想在构建完成后发个Webhook通知下企业微信或者钉钉消息
✏️ 划重点
持续集成是保证软件质量非常重要的一环，贯穿整个流程需要Jenkinsfile来驱动它，我们这里采用集中式Jenkinsfile来管理所有的服务，另外构建要恒定从一个分支去做（Hotfix除外），确保构建出来的制品可以发布至任意环境，步骤如下
⛏️ CI
- 动态拉代码，从Jenkins Job中传仓库名做参数
- 跑单元测试，Jacoco插件生成报告
- 通过Sonarqube做静态代码扫描
- 打包
- 构建成Docker镜像
- Push到镜像仓库（Harbor）
- 留存构建记录
👨💻 CD
- 制作服务发布的K8s yaml文件
- SCP到K8s集群服务器
- Apply yaml文件替换新版本镜像
- Webhook企微或钉钉发布结果通知
- 触发自动化测试任务，执行回归测试
- 留存发布记录
自动化测试平台
这个平台会管理所有与测试相关的脚本与Case，通过与CD流程结合，把每次发布后的测试结果留存，它的最主要的责任是将回归测试、集成测试、UI自动化测试、性能测试脚本的执行和报告的采集，透过数据第一时间监控服务质量。
最后推荐下K8s集群管理工具 Kuboard 好用！
基础设施
如果你公司没那么大的财力，我劝您还是老老实实用云服务吧，养着几十号人运维着一个IDC机房，每天还得提心吊胆怕出事故，真的是没必要，现在的云服务绝对比你想想中要好用的多，完备的监控体系，有保证的SLA，就算是真出了意外你也可以要求索赔，自建的IDC机房我是亲身体会过当电缆被挖断时全线宕机的无助，你只能祈求下次挖掘机给点面子。
如果你只做国内业务，阿里云是首选，如果也要兼顾海外业务，那么选择AWS绝对错不了，但你说开始业务没扩张没考虑到海外业务先用了阿里云到时候迁移麻不麻烦，跟迁移相关的无论啥事情都挺麻烦的，劳神费力，我建议最好在期初就选择，如果真的遇到切换供应商的情况，从架构设计上我们能做点什么？那就是减少对云服务中间件的依赖，本着能不用则不用的理念准没错，这里不包括RDS相关的服务。
结尾
你既然都看到这了，那我猜你可能还意犹未尽，这篇文章只是把整体架构需要用到的板块介绍了下，如果你觉得还不错，麻烦推荐给你的同事和朋友，择时我会深度剖析每个板块具体落地方案。
