【架构师实践课】单体和微服务怎么选？单体到微服务怎么转？
在七牛云与 ECUG 联合推出的线上系列分享活动【七牛云架构师实践课】中，七牛云技术副总裁、go-zero 作者万俊峰为我们带来微服务系统设计专题的首个议题——单体和微服务的选择。
以下内容根据实践课整理。
大家好，我是万俊峰，熟悉我的朋友都知道，我是做微服务相关工作的，是开源的 go-zero 作者。
我们在做服务端的时候，其实有另一种选择方案——单体。在我的实践中，很多大型业务也都是从单体服务一步步演进过来的。所以今天我主要想和大家探讨的问题是，单体和微服务应该如何选择？从单体到微服务的改造，应该如何进行？
单体和微服务如何选？
首先从单体说起。很多人在业务初期会有这样的想法，先找个微服务框架，再做一系列设计和架构。其实在业务起步之初，这种情况很常见。大家都知道对一个业务，特别是创业公司来讲，成功概率是非常低的，可能做了一年半载，用户只有几万乃至几千，项目不一定能起来，此时就未必要使用微服务的方案。
所以我根据自己的经验，想和大家分享创业或小项目，应该如何一步步往前走。
针对目前的情况，移动互联网肯定是占大头，所以业务有手机端，如果更友好一点会做桌面端。那么对我们来讲，项目之初可能只有一个单体服务，后面挂一个 DB。在一般情况下，我们会有静态资源，挂一个FileServer，比如说 Nginx 之类的，这样都可以进行访问，对小业务而言已经可以跑通了。
但是随着业务发展，这种场景能支撑的量是比较小的，而且它没有对故障容忍的方案。所以说当业务有一点发展以后，我们可能就会用到这样的方式。也就是在前面挂一个 Nginx 作为反向代理，后面再挂三五台主机，这样就可以支撑好几倍的量了。
其实这种方案跟第一版的架构没有太多变化，但是其实比较容易得到横向的扩展，不需要去改写，只是布了多个节点。只要 DB 稍微升级一下，特别是云原生时代大家使用云主机，升级非常容易，在业务发展之后稍作改造，就又可以承载业务往前发展了。
当业务继续发展，可能一台 Nginx 就不够了，需要配置多台 Nginx，比如把 Nginx 在 DNS 上面去配一些记录，就可以在 Nginx 做随机负载均衡。同时面对文件系统变多的情况，我们可以加一点投入，比如买七牛云的 OSS 存储，因为对于 OSS 来讲，很多时候 SDK 是集成在客户端的，你可以直接去使用，就会把存储从 Nginx 剥离掉。
那么对于 Nginx 来讲，可能就用几台服务器，组成之前那样简单随机的轮循。从单体来讲，在不做任何拆分的情况下，就可以放到后端的 Kubernetes 集群里面去了。此时还是一个单体的状态，只是放在 Kubernetes 上面，也就是在多个节点上跑。之后就可以直接买云厂商的 RDS、DB，特别是云厂商的 DB 扩容简单，可以承载很大的规格。在这种架构下，能承载相对来讲比较高的并发量和用户量，此时再用redis做一些缓存、临时存储，我认为这种架构就可以承载很多初创公司的前期业务发展阶段了。而且这个架构非常非常简单，不需要有太多的运维成本。
在这样的情况下，可以打一个 docker 的镜像，不一定用完全自动化的 CICD 流程，业务价值已经得到很好的体现。所以在做架构的时候，我一直强调不能脱离业务去看技术。正如把大公司的复杂架构放到小公司就行不通，技术架构过于复杂反而会阻碍业务的发展。因此我做 go-zero 有一个信条——一定要保持简单。在业务适当的时期，我们要保持业务架构足够简单。
当然在简单的同时，我们有弹性和前瞻性。所以我想和大家聊聊业务架构什么时候该去升级。
在系统出现一些故障，开始冒烟的时候就要进行规划，永远不要等到它真的着起火来。同时要结合业务，和业务部门或者公司老大多沟通预期。但同时不要过于超前，用一个巨大的复杂系统来跑简单业务，也是不合适的。我以前做过的好几个大的项目，都是从单体一步步往前走，后面再拆成几十个上百个微服务，支撑大体量的业务。
讲了这么多，我们来看一下单体的优点和缺点。
单体的优缺点
首先第一个优点，单体对我们来讲开发真的很简单。对 go 来讲就是一个二进制文件，你 build 完了，打一个 docker 镜像，把它上传到云厂商一般都会的有私有仓库，你也可以用 go-zero 提供方法，帮你一键做出一个大概 10M 的 docker 镜像。这和以前 java 几百 M 甚至几个 G 的镜像是很不一样的， go-zero 也自带Dockerfile 的生成方法。
同时单体的测试很容易。在社区里经常有人问微服务怎么调试？这是很难的问题，如果我有上百个微服务，在本机上全跑起来，公司要么给每个人配一个顶级的电脑，成本高昂，要么提供开发的环境，需要多租户，否则相互之间会有影响。但是单体的测试就很容易了。
单体的部署也非常简单，因为相互之间没有依赖，不会互相影响。我们写单体的时候，发版就好了，不会说要找谁分析依赖关系，大家没有太多的心智负担。
优点说完了我们来看缺点，我认为最大的缺点就是扩展难。业务发展以后，功能越来越多，但凡加一个服务，全局可能受到影响。同时小改动导致全量更新，我们曾经就遇到过类似问题，更新了一个小功能结果导致整站挂掉。所以任何一个改动就要全站更新。而据行业不完全统计，基本上 80% 以上的故障都是更新导致的。所以小问题引发大故障，是蛮严重的问题。最后就是单体承载的业务规模非常有限，因为业务规模大了以后，人、业务、数据都会很多，很难通过服务拆分的方式，去承载业务规模的增长。
以上就是我为大家总结的单体优缺点。
微服务概览
咱们接下来可以看下图，如图所示有 5 个微服务，每个微服务都有各自的 DB，每个 DB 上面对应自己的微服务。
所以我一直在强调，我们每一个微服务，应该有自己的 data store，不应该直接访问别人的 DB，这是非常非常重要的点。我们在微服务上有 API getaway，通过 API getaway，让 A 服务就到 A 服务，B 服务就到 B 服务，我们会梳理倒流过去，这是微服务的架构。看起来很简单，但是其中每一个环节里面都有承载者，都包含着刚才单体服务的引进。这是微服务的概览。
微服务优缺点
刚才讲单体我们曾提到，不一定每个小功能都独立成微服务，一般从粗到细来逐步分拆，每个里面都包含了刚才单体的一些 CICD 流程等，可以说这就是把不同服务之间做了比较好的隔离。
在这种情况下，我们先来看看微服务的优点。
我们可以边界清晰地把业务做拆分。正如刚才的图中，五个微服务底下分别都挂了自己的 DB，DB 之间、微服务之间不可以访问别人的 DB，就让数据得到清晰拆分。而数据拆分是微服务的根基所在，数据拆分做不好，微服务基本是白搞。
同时，由于每一个服务已经进行了拆分，所以当我的业务发展到一定程度之后，开发起来就比较容易，便于大家理解和维护。
微服务中的技术栈相对来讲也是比较独立的，你可以使用不同的技术栈来开发各自的微服务，当然我不推荐这样，我的推荐是技术栈要统一，这样技术交流比较方便。但是如果公司比较大，可能不同的服务需要使用不同的语言，那么技术栈独立就是一个优点了。
易于做持续集成和部署，也是微服务的优点。它任何时候都可以更新，不至于影响全站，更新有问题以后也可以降级。比如说某个服务有问题了，在go-zero里面提供了降级的fallback机制。
在微服务中，对不同的服务需要有不同的治理等级，重要业务重点治理，非重要任务因为请求量较小，我们也不会有那么复杂的治理。
微服务的优点中，很重要甚至是最重要的，就是稳定性比较容易保障。某一个服务把整个全栈拉垮，是基本不存在的。
但是微服务的缺点也很明显。
首先就是看起来复杂了，本来单体可以搞定，现在一大堆放在一起。另外数据拆分的复杂度也不能忽视。对于数据拆分就需要一定功底，如果说微服务交给一个新手来做，其实挺难。这也就是我说在业务早期，可以先用单体的原因。同时微服务调试比较困难，比较难做详尽的测试。跨服务的修改，相对来讲也是比较比较麻烦的。微服务的部署也是一个难点，因为它有依赖关系，我在团队里要求所有的服务要按照时间来打标签，需要我们每天都检查所有的deployment 的部署时间。在实践中，我强制要求我们团队，所有的部署必须在 3 个月的时间里尝试更新一次，确保不会留过多的技术债务，这也是一个可以分享的点。
以上就是单体和微服务各自的优点和缺点。那么新的问题就来了——单体和微服务，到底怎么选？
到底怎么选？
以下图为例，左边就是单体，把各种服务放在一个五边形里面。右边的是微服务，各自拆分开，变成了五个。所以说简单肯定是左边单体，微服务比较复杂。选择起来我觉得要从四方面考虑。
一是看业务。小的公司小的业务，刚开始尝试的时候没必要引入过多的复杂度，是可以用单体的方式来往前跑；二是看团队。比如在一个大的公司里面，其中本身就是微服务体系，其实没有任何开发的心智负担、运维的心智负担，同时一般做一个业务会有体量预估，有一堆资源去推动业务往前走。这种时候你是可以根据自己的需要，来选微服务的；三是从简单入手。以我现在做的业务为例，体量还是不小的。但要快速满足业务价值的交付，一开始也是从单体起步，后面再来拆分。只要把前后事情隔离清楚，就是非常容易做的。因为对前端都是无感的，那我后面从单体往微服务转，只是后端的事情，这也是第四个要点——预留可能性。
从单体到微服务转换的信号
如果一开始用单体走了一段时间，那么什么时候该去考虑往微服务转呢？我分享以下这些信号供大家参考。
首先就是你感觉这个单体服务已经过度复杂了。这是一个主观的体感，就是你觉得这个单体我写了也不敢部署，一部署就怕全站挂，代码已经搞不清楚了，要问一圈人去判断改代码的影响。如果你有这个感觉，可能就是要转换的时候了。
另外就是单体已经不能满足当前的业务发展需要。比如我之前曾接手一个大型系统，业务基本上每周都要宕机好几次。当前的架构满足不了高并发和性能的要求，这个时候需要去转。
当研发效率低下的时候，也需要转。虽然我管团队很多年，但是我基本上每天写代码，也跟大家一起看代码。我喜欢了解大家时间是怎么安排的，有一阵子大家跟我说，我们最后一天是留着去merge代码的。我觉得这个成本挺高挺浪费的，就去了解为什么。大家merge代码，出现几百个文件都已经修改并要 merge的情况，这样就可能把别人提交的代码冲没了。这种局面下，研发效率已经很低，改也就是必须的了。
还有一个判断的点，就是当运维和开发不太敢更新的时候，就需要改变了。在单体中，高峰时间不能更新，更新风险的大家也不愿承担，你也等我也等，等到有一堆修改才去更新，这样有问题也很难知道到底是谁的代码导致的了。
最后我想说的情况，是团队人比较多的时候。很多人在在一个服务一个单体上搞，十有八九是要出问题的。这种情况下要考虑做转变了。
单体到微服务怎么转？
我做过多次单体到微服务的转型，也总结出很多经验和教训，希望能给大家一些借鉴。
我在几次从单体到微服务的转型过程中，都是可以做转型决定的，但也肯定会跟 CEO 商量，讨论对业务影响要怎么样去规避，对公司层面给出一个预期。如果我投入比较多的人力做转型，肯定会影响到业务的迭代，造成一系列的问题。这一定要有心理预期，转型过程中，不太可能零故障。所以说转型过程好比开着飞机换引擎，这是大家经常听到的一句话。
这个过程中，最难的一件事是什么？就是敢做这个决定。这件事情是头等重要的事，需要一个勇于扛责任的领导，有决心的领导。如果没有决心，那么后面一切都是空谈，而心够决，这件事就成功了一半。
在下定决心之后，我们要充分调研必要性、可行性。或者说下决心之前就要有充分的调研。云原生发展到今天，基本上来讲不会有可行性的问题，必要性是重中之重。我分享一下我做技术选型的经历，之前系统是 java 做的，是很大的一个整体。那么出了问题以后，谁也搞不清楚，只有靠重启能搞定了，有时候重启就要花两个小时。所以我接手这个团队的时候，就坚决要转，只要还想继续业务发展，就必须要重构，必须得重写，必须得做技术转型，所以我们就转。
转的时候也需要充分的技术选型考虑。比如在上述情况下，我将 java 转成了 go，其中一个很大原因，是我不希望原来的团队从原来的代码里面，拷贝出原来的业务逻辑。因为你要知道，程序员想做一件事情，最快的方法就是复制粘贴。我完全换了一个语言，就只有理解原有代码，去重写它。我们既然从头开始，我就希望项目一定是从根本出发，排除原来的干扰因素，去除一些惯性的思维。
据说谷歌每三年重新书写一遍系统，原因就在于它要保证 4 个 9，在系统写完后，大家对新业务系统了如指掌，有任何问题可以在很短的时间里分析并解决。我们大概花了五个月的时间写完，之后三年时间都没有线上重大故障。
虽然最终的结果令人满意，但是项目之初，是没有成果可以展示的，如果刚好遇到述职，你也没有东西可讲。万一领导说这个不行，没有产出不要干了，整个事情就报废了。所以说得到公司和部门领导支持，也是非常重要的。
最后我想分享的是，大家一定要关注迁移核心团队的能力，包括经验、执行力、自驱力。组成精干核心团队的时候，一定要选择有经验、执行力强、有自驱力的团队成员，大家遇到问题不放过，形成最佳实践，然后才能逐步推广团队做改造。
微服务的改造策略
我们在微服务的改造中，需要要讲究策略。
初期要挑选精兵，在改完之后这些精兵可以变成项目的核心人员。比如我之前例子中微服务的五个部分，我每一个都需要核心人员把控质量。在前期的时候，打磨的不光是产品和架构，更重要的是人。人打磨出来以后，后面的项目往前推进，就会非常容易。
同时在改造过程中，我们要把握从外往内、从边缘到核心的原则。一定要有业务预期，一定要有故障的预期，从外往内也就是让故障可控，让问题在非核心的地方先暴露，这样再往核心逐步推进。
接下来我们要关注数据的拆分、迁移和验证。数据如果不正确，基本上来讲改造是白改。而且在改造的过程中，特别特别重要的一点就是一定要可回滚。你不能说改了，上了，挂了，业务没了。所以说改造的过程中，一定要让业务可以回滚到原来的系统里，让它能跑，这样一来就不用那么提心吊胆，心态上就轻松很多了。
我们在改造的时候，最好每天都要复盘，改造过程一般不会太长，半年时间基本上主体的改造就能完成。这个过程中，越早期越要多进行复盘，这样能越早总结经验教训，加速改造。
最后一点也非常重要，就是成果要及时回报。比如之前的项目做了五个月，开学前上线后服务增长了四倍，非常平稳效果很好。但是这五个月中如果缺少汇报，领导就不知道你在干什么，价值在哪里。所以汇报不是为了邀功，更重要的是管理预期，让改造能平稳地执行下去。很多技术人不太关注这个点，但其实挺重要的。
以上就是我今天想和大家分享的内容，在下一讲中，我会和大家分享微服务的设计痛点，欢迎大家持续关注。
【架构师实践课】单体和微服务怎么选？单体到微服务怎么转？相关推荐
- 【架构师实践课】微服务如何拆分？大型微服务项目从何下手？
继上期[架构师实践课]单体和微服务怎么选?单体到微服务怎么转?之后,万老师为我们带来了微服务系统设计专题的第二个议题:微服务设计痛点. 以下内容根据实践课整理. 微服务如何拆分 首先想和大家分享的,就 ...
- 架构师实践日 11.9 南京站报名 | 技术大牛带你剖析大数据平台内部演进中的挑战与实践...
从互联网时代到物联网时代,数据成为了企业的核心资产,挖掘数据价值成为了企业数据探索.技术应用的重中之重,甚至将影响到企业未来的发展和商业模式.但大数据体量大.多样性.价值密度低.速度快等特征,也给大数 ...
- 如何构建 FinTech 科学反欺诈体系|架构师实践日
微众圈 > 微信资讯 > 科技 > 文章 如何构建 FinTech 科学反欺诈体系|架构师实践日 摘自公众号:七牛云发布时间:2017-4-11 21:28:33 FinTech,即 ...
- 转：架构师实践日｜亿级短视频应用秒拍的架构实践
转自: http://mp.weixin.qq.com/s?__biz=MjM5NzAwNDI4Mg==&mid=2652190131&idx=2&sn=6672422564e ...
- 架构师实践日 · 6.30 杭州站 | 视觉 AI 技术如何助力行业提升？来西子湖畔与业内大咖面对面交流！
伴随内容形式的变迁(文字 → 图片 → 视频),目前视觉 AI 技术不仅被应用到传统领域的升级革新中,还作为最重要的基础人工智能技术渗透到前沿技术的创新研究中. 七牛架构师实践日第二十九期将以视觉 A ...
- 《App架构师实践指南》：移动开发的进阶指南
文章主要内容: 什么是 app 架构师 这本书主要内容 读完感受 什么是 App 架构师 成为"架构师"是许多程序员的梦想,当然也包括我,在工作的几年里,我见过很多架构师,他们在设 ...
- 读了本号称“App架构师实践指南”的书
大家好我是张拭心,最近读了本书,书名比较厉害<App架构师实践指南>,读完还是有一定收获的,记录分享给大家. 什么是 app 架构师 这本书主要内容 读完感受 什么是 App 架构师 成为 ...
- 软考高级系统架构设计师：基于ODP的架构师实践
软考高级系统架构设计师:基于ODP的架构师实践 一.基于ODP的架构开发过程 二.系统构想 三.需求分析 四.系统架构设计 五.系统转换.操作维护和系统移植 六.基于ODP的架构师实践相关知识点 1. ...
- 阿里P8架构师谈：Restful、SOAP、RPC、SOA、微服务之间的区别
内容大纲: 1.介绍Restful.SOAP.RPC.SOA以及微服务 2.重点谈谈SOA与微服务的区别 3.以及为什么要使用微服务架构 什么是Restful Restful是一种架构设计风格,提供了 ...
- 阿里巴巴P8架构师传授的这份在GitHub标星75K的微服务笔记为何有如此大的魅力？
今年的疫情让各位码友们的处境都十分困难,但是我相信大家都能迅速调整好心态,在空闲之余抽出一点点时间用来学习,学到就是赚到,坚持学习技术知识也是对自己百益而无一害."金九银十"也在一 ...
最新文章
- 5g通用模组是什么_广和通发布全新5G模组FG650，搭载展锐中国“芯”
- 【网络编程】之十、重叠IO Overlapped IO
- ANN：ML方法与概率图模型
- 将excel转为python的字典_python读取excel表并把数据转存为字典
- Halcon例程（基于多个标定图的单目相机标定）详解—— Camera_calibration_multi_image.hdev
- 【渝粤题库】国家开放大学2021春2608中级财务会计（二）题目
- NOIP前夕：noi.openjudge,Maximum sum
- 指针结构体函数-事实上能够这样具体理解
- 云图说 | 通过Helm模板快速部署中间件应用
- 关于C#调用protobuf 序列化和反序列化
- Mysql 基础知识
- Linux安装GCC方法
- 基于springboot的疫情社区管理系统
- 水系图一般在哪里找得到_Nano Energy：铝离子扩层V2O5nH2O用于高性能水系锌离子电池...
- 高精度信号链电路精密模拟器件双轨供电方案
- ArcGIS根据矢量图层范围裁剪影像
- 英文原始文本的读取与处理
- STM32L431 I2S/IIS slaver使用
- html 发言样式,HTML样式
- 一个有趣的网站:子说