今天这篇文章咱们继续说架构师大刘的故事。程序员
故事纯属虚构，别对号入座哈。数据库
前言
大刘日子最近还不错，常常午睡醒来，就继续拿着手机看小说摸鱼。大刘对当前所在的这家公司比较满意。大部分系统已经成熟稳定，用户量也中规中矩。虽然有些项目技术陈旧，但好处是没啥幺蛾子技术问题冒出来等着解决。安全
只是有时候大刘内心会打鼓，公司盈利在降低，巅峰不在，也不知道这家公司能撑多久。除了偶然会冒出些对工做稳定的担心之外，大部分时候，大刘心情都是愉快的。直到他被领导叫到办公室分派新任务的那一刻……服务器
大刘的领导 CTO 老李，这些日子心情不是很好。他在的这家公司本来是个以传统业务为主的公司。为了跟上互联网时代，大老板拍脑壳成立了个技术部门搞互联网。虽然说公司已经号称触网了，可是公司盈利基本仍是靠传统业务，技术部门只是打辅助的。没有业务主动权，没有盈利点，部门员工的工资却都不低，老李的地位就可见通常了，常常受些冷言冷语的夹板气。再加上，最近公司的效益也有所降低，眼见技术部门面临着裁人的危险。老李危机意识被极大的刺激到了。网络
老李是个技术出身，可是离开一线编码已经快十年了，天天的工做其实就是管理加玩概念。这几年微服务的概念很是火爆，老李一直想着能搞点这种热门东西，而后再拿着这些作出来的新概念技术，给那个不懂技术的大老板展现下本身的两把刷子，同时也能打响在业界的名声，对本身的职业发展也大有好处。趁着构思部门前途这时当，老李认为这也是搞微服务的好时机，同时也想到了有微服务经验的大刘。因而，大刘就被召唤进了办公室……架构
通过了几个小时的讨论，大刘面带无奈的接下了这个任务。这个任务是这样的：运维
把公司里几套运行多年的核心系统改形成微服务。分布式
这些个老系统当初是按照几万用户量的目标去设计开发的，虽然如今跑着没问题，可是眼光要看长远，产品和技术们将搞一套更高级的东西，目标是这套系统会被几百万人使用。模块化
OK，微服务使用的前提出现了。微服务
大刘来这家公司以前，在某电商大厂干了多年，对微服务在电商系统中的应用这块有实践、有经验。对微服务这块，大刘是吃过猪肉、也见过猪跑，还被猪咬过……嗯，对，还被咬过不止一口两口。因此，对改造微服务这个任务，大刘是硬着头皮接下来的。
大刘虽然无奈，可是看在工资的份上活还得干。不过槽仍是要吐的，因而下班后大刘用了几小时码出了下面这堆内心话。
正文开始（如下是大刘的第一人称）：
—0—
最近，常常有同事和我聊微服务，也屡屡指望对公司已有项目进行改造，但愿能把全部项目改形成微服务方式。我对此常常很无语，也屡屡对这些人进行劝阻。
我认为，劝我改造微服务的人之中，有一些人纯粹的对技术痴迷太深。更甚些，我甚至能够说这些人中的某些人就是纯粹的自私自利。搞微服务难道不是为了蹭热点，为本身的简历增色，为下一步跳槽涨薪作准备？未尝想过微服务为公司带来的各类坏处和所以而来的成本提高？另外有些人，则纯粹是被外面铺天盖地的微服务概念给打晕了头，被各类微服务成功故事洗了脑。这些人，把微服务当成了万能药，纯粹就是脑壳犯了糊涂，陷入了惟技术论。
为了说明微服务不是万能药，这里咱们就先要说明下微服务的概念。同时呢，咱们也须要诠释清楚微服务的优缺点，看看何时用微服务，何时不用。
什么是微服务？对于微服务的定义，网上众说纷纭，并无一个权威的定义。可是在这些纷繁复杂，云山雾罩的各类微服务洗脑文和说明文以后，老是有一个统一的基本面在：即微服务是一种利用分治法的思想，去把一整套很是复杂的业务逻辑给切分红多个简单的业务问题，并采用模块化方法去实现组合的一种架构方法。
这么说是否是还很抽象呢？好，我们再更深刻的解释下，并顺便把微服务的优缺点也所有一并说清楚。
—1—
首先，微服务是采用分治法思想，须要对业务逻辑作分解。作完分解后，还须要多个对应的实现模块去实现分解后的业务问题。这些模块的开发和维护，是都须要成本的。若是咱们要搞微服务，考虑过开发维护成本吗？
上面这图代表了，从项目一开始，微服务的代码开发和维护每行平均成本就很多，随着项目规模和系统复杂度的上升，代码的开发和维护平均成本才会缓慢降低并逐渐收敛到某一个值左右恒定。
而单体项目正好相反，一开始，单体项目的每行代码平均成本是比较低的，随着项目规模和系统复杂度的上升，代码开发和维护成本会慢慢上涨，后续可能复杂度和开发成本会愈来愈高，一直冲上天际。
这时候，就不得不迫令人们去找到一种比较合适的方法，能把开发和维护成本下降到项目团队能够承受的程度。
这就是引入微服务的意义所在。
可是，全部的项目会一直发展下去吗？全部的项目会永远运行并扩展吗？
有不少的架构师或者技术人员，在一开始作架构和系统设计的时候，不考虑实际状况，在公司给出一项很紧迫的任务以后，不去考虑实现时间和开发成本，上来就搞高大上，起手就是微服务，这现实吗？
咱们这些技术人员看过许多鼓吹微服务的技术书籍，也看到过不少微服务的“成功学”，可是他们的前提是什么？他们对微服务的说法通通是创建在一个只有技术存在的完美世界里，把现实世界他们认为的一切杂音都摒除在外，这合适吗？
咱们在作架构师以前，第一个考虑的应该是投入和产出。当然，咱们从技术角度考虑，必定会要考虑可扩展性，可维护性之类的技术指标。可是，咱们也须要根据当前项目的重要程度，盈利前景，还有可用服务器资源等，做出本身的平衡来。
—2—
第二，微服务的另外一个优点是弹性化。什么意思呢？就是咱们在业务逻辑改变时，那些对应业务逻辑改变的功能的增删改，开发和部署成本很低，能够像弹簧同样，自由的缩减和增长。
而且，微服务里最佳实践是每一个分出的模块应该都有本身的数据库，和别的微服务并不共享任何数据库。因此微服务自己认为，每一个微服务模块的数据库均可以不同。
好比咱们开发一个电商网站，若是搞成微服务，大概以下:
若是咱们的业务逻辑作了一些调整，好比，咱们想要增长一个积分功能，那么，咱们只须要再增长一个叫作积分的微服务便可。
这就是微服务的便利之处。
可是，咱们认可吧，并非咱们所作的每一个系统都足够大，都大到须要分解成更多更小的服务。那些不是太复杂的系统，它们凭什么须要弹性化？凭什么须要切分业务，从而搞出一大堆的项目出来呢？
另外，微服务的弹性化带来的问题就是，咱们须要管理由于弹性化所切分的许多小项目，须要搞出一套易用的自动化管理系统，须要把公司的底层基础设置打造好，请问，这些成本，你准备付出了吗？
在这个现实的世界里，并非一切围绕着技术打转的。当然，技术欠债会让咱们这些技术从业者感到分外的困扰和难受。但是，假如咱们超前超度的使用了咱们可能并不须要的超前概念和超前架构，一样会使咱们感到痛苦。
若是咱们控制住了本身的技术欲望，咱们是否是从自身也控制了一部分技术欠债呢？这是一个架构师应该要思考的地方，也是咱们不该该滥用微服务的缘由之一。
—3—
第三，微服务起手就是分布式。分布式我认可有各类各样的优势，可是，分布式引起的各类问题和所以须要引入的各类技术解决方案自己也有自身的问题。
好比，分布式事务。在引入微服务前，咱们做为架构师，必定要思考后续是否是可能出现跨服务的事务。兄弟，分布式事务你们都知道有多困难的。
按照微服务的标准，服务之间的通信应该尽可能采用简单的 RESTFUL 协议。那么，根据这种规范，若是咱们采用了微服务方式架构，咱们的每一个项目都应该搞成 REST 服务。REST 服务自己就是无状态的，如今，若是业务里出现了严重依赖状态的跨服务事务，想一想吧，你会面临什么：
分布式锁方案你是否是要考虑下？分布式互锁后，出现了死锁，你的追踪策略是什么？若是出现了竞争资源，致使服务状态不一致了，你怎么去快速恢复？数据腐蚀你有办法吗？
什么？你告诉我我说市面上有不少成熟的分布式事务解决方案？别自欺欺人了，我们都是搞技术的，请问，你说的是两阶段提交（2PC）吗？好吧，你们都知道 2PC 那可怜兮兮的性能。
好吧，那三阶段提交（3PC）呢？它的不一致问题曾经让咱们彻夜难眠。
搞 TCC 或者 SAGA 呢？对不起，由于最终一致性所添加的业务紧耦合的各类消息和通知，会直接犹如 24 小时的梦魇，可能会是压垮你的最后一根稻草。
微服务的提倡者老马丁本身也说，微服务引入了最终一致性问题。
对于原来单体项目很简单的事务问题，在微服务中，是一个使人皱眉的困难问题。全部微服务的开发者，在开发微服务代码以前，都须要考虑怎么能探测到数据不一致的问题。不然，必定会万分后悔。
那么，分布式事务会不会必定会出如今微服务中呢？从目前来看，几乎没法避免。为了搞定这些问题，微服务实现每每还须要伴随着实现一整套构建在无状态服务之上的调用链。
对于这些额外的开发成本，咱们有必要吗？是全部项目都须要的吗？不是吧。这就是咱们架构师须要考虑的问题，也是咱们须要谨慎和妥协的地方。
—4—
第四，微服务互相之间是经过网络通讯配合起来来对外提供服务的。这就会带来一个依赖性问题，即微服务很是依赖底层网络的健康。
若是网络通讯之间出了问题，总体对外的服务质量就会下降到极其让人难以接受的程度。
而且，网络通讯自然就必定会带来延迟。原本单体项目咱们好好的，你们都是在内部互相通讯，延迟基本能够忽略不计。
如今，你们分开了，互相得远距离打招呼，延迟动不动就来个几十毫秒几百毫秒延迟。这些延迟，咱们也须要考虑在内，必须通过严格的测试才能够。
另外，网络通讯出现问题后的各类容错方案，也必须考虑完善。以上说的这些，也都是一个合格的架构师必须在微服务引入以前，所要进行的综合的考量。
—5—
其余：微服务的引入还有各类各样的问题，包括:
-
额外引入的复杂性
微服务在上面我也说过了，会带来各类各样的成本的提高，也会引入各类各样的技术问题。这些最终就会致使总体系统复杂性进一步的提升。当复杂性提升的时候，为了保证系统的稳定，就须要总体技术团队的靠谱，就须要技术人员的靠谱，就须要总体技术设施搭建的靠谱。在引入微服务以前，各位兄台麻烦扪心自问下，这些贵公司有吗？有这些团队、这些设施、这些资源吗？ -
分布式自己带来的成本
分布式自己就须要一整套完整的技术体系和设施去支撑总体分布式的建设。好比，之前单体项目只须要一个项目，直接人工上线就行了。如今呢，可能会出现几十个上百个项目，这些项目若是全靠人工去作，会完全让团队人员疯掉。因此，就须要把总体发布，部署自动化起来。这里还仅仅是发布部署所须要的，尚未谈维护问题，用《征服》刘华强里的一句话说:”你有这个实力吗？” -
维护和监控微服务所须要的 DevOps 团队
微服务自己须要维护和监控，以确保运行的稳定和可靠。在微服务的最佳实践里，是很是推荐搞 DevOps 的。我暂且不说 DevOps 须要的对人员水平的高要求，我就说 DevOps 自己所须要的工做态度和责任心问题，本身家的运维团队搭建是个什么鸟样子，运维整天忙死了再干吗，谁还不清楚吗？总体运维的平均水准加上开发水平的要求，这个团队搭建下来要花多少钱？公司舍得这些投入吗？ -
微服务自己所须要的经验
微服务自己是很复杂的，从设计划分模块开始，就须要架构师必须对架构设计和微服务自己对应的 DDD 领域驱动设计很是有经验，可以恰到好处的划分出对应的模块。不然，一旦设计完毕，不巧把一些紧耦合的服务给硬是解耦成了不一样的服务，那么，这个后果对整个技术团队甚至对整个项目团队都是灾难性的。同时，对于微服务的开发、维护、运行、保障以及运维，都须要技术团队成员要有很丰富的从业经验能迅速发现，定位，解决可能随时出现的问题才能够。若是技术问题不能及时解决，那总体系统的体验就可想而知了。可是，如今的经济环境，如今的公司技术人员构成，肯定能有这些很丰富经验的人员来搞微服务吗？ -
链路测试的方法
咱们上面提到过，为了快速追踪定位死锁或者共享资源的问题，微服务须要靠谱的调用链实现。那么，这就引出的新的问题：咱们如何搞全链路测试？咱们是否是还得搞一套合适的全链路测试工具才能够？这全链路测试工具开发又须要花多长时间，须要投入多少人力？测试人员的水平是否是也须要获得必定的保证？ -
微服务日志的爆炸
微服务自己有多个节点，这些节点为了本身的安全运行和维护，须要不少本身独有的日志。这些日志随着微服务的增多，也愈来愈多，你如何存？如何查？如何删？这些是否是都要考虑在内？
以上说的这些问题并非否定微服务。
我只是砸给那些劝我没事儿就搞微服务的人。对于这些什么都不考虑，上来就说微服务的人，我认为都是非蠢既坏。
无论不顾现状，没事儿把微服务挂嘴边动辄怎么怎么样的人，我劝你悠着点。
最后
写完以后，大刘感受长出了一口胸中的闷气，过完嘴瘾，内心也痛快了。如今大刘最担忧的是，这些文字千万别被领导看到……
最最后
大刘的故事讲完了，我再啰嗦一下。微服务确定是先进的，可是都已经 2021 年了，不用我再和你们介绍微服务的优势了，那也太俗了。
但愿你们看完能明白，并非什么新科技，热概念都适合本身的团队、本身的项目的。作一个合格的架构师、技术负责人，首先应该遵循的是 KISS 和 YAGNI 原则。
请各位技术人员永远保持理智，咱们要作的是选择正确适用的技术而不是选择本身最喜好的技术。请不要作那种把简单的事情往复杂里作的技术疯子。
你好，我是四猿外，一家上市公司的技术总监，管理的技术团队一百余人。
我从一名非计算机专业的毕业生，转行到程序员，一路打拼，一路成长。
我会把本身的成长故事写成文章，把枯燥的技术文章写成故事。
欢迎关注个人公众号，关注以后回复“666”，送你一些珍藏的资料，帮助你提升技术、进大厂拿高薪。