背景
工夫回到 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 相干的服务。
结尾
你既然都看到这了，那我猜你可能还意犹未尽，这篇文章只是把整体架构须要用到的板块介绍了下，如果你感觉还不错，麻烦举荐给你的共事和敌人，择时我会深度分析每个板块具体落地计划。