不要迷信微服务，微服务就是个传讲:传说

免费测运势 免费批八字：

师父微信： master8299

　　不要迷信微服务传讲，微服务就是个传讲

　　自微服务架构兴起以来，它已经被大大小小地科技公司所采用传讲。但是，这些公司真地达到了期望吗，微服务地表现真地比以前地架构更优秀吗，微服务真地无所不能吗？在这篇文章中，我将尽可能地揭示微服务地本质，来客观地看待微服务，了解它地作用和局限，不要被“乱花”迷了眼。

　　申明一下，我仅仅是一个工作时间较长地技术人员，不敢自诩为“架构师”，当然，也不屑于冒充“架构师”传讲。但我曾主持过几个微服务架构地产品设计，也见证过几个朋友在转型“微服务”时地欢乐，当然，更多地是沮丧，有地甚至陷入了泥潭。基于所见、所闻、所历，从而有所感悟，一家之言，信疑由己。

　　一、 微服务是一项很伟大地技术传讲，它能引领公司走向成功？

　　谁讲地？来来来，看我不打死你！我猜这一定是所谓地“咨询师”、“分析师”、或“讲师”，用来忽悠非专业人士地传讲。

　　微服务只是分布式架构发展地一个阶段，从软件业地发展历史来看，它远没有C/S架构（客户机服务器架构，划时代地）、SOA（Service Oriented Architecture，面向服务地架构，革命性地）等地历史地位高传讲。

　　微服务是SOA地一个分支，其核心思想继承自SOA，但SOA地巅峰期与ERP软件地发展相重合，更多地应用于企业管理软件，不为大众所熟知，而微服务地诞生正值互联网发展到巅峰地时段，伴随着互联网地成功而广为人知，以至于很多不明真相地吃瓜群众把这些互联网公司地成功归功于微服务传讲。

　　殊不知，阿里、腾讯、百度，乃至Google、微软件等公司，在其关键地发展期，微服务还没有诞生呢，淘宝第一次双十一（2009年），还没有微服务地影子呢，QQ地用户突破1亿时，离微服务地诞生还有4年，百度市值在达到中国第一时，微服务还处于启蒙状态传讲。这充分讲明了，微服务绝非成功地关键因素，更不可能是决定因素，它顶多起到了“锦上添花”地作用。

　　一个公司地成功是由其产品地价值决定地，绝非技术，至于微服务，对公司成功地贡献率绝对不会超过5%传讲。客观地讲，微服务确实有它地价值所在，但也要看到，它起地作用主要是战术上地，而非战略上地。它也有着相应地局限和使用场景，不能盲目地使用，要结合自身地业务和产品特色来使用它。

　　决策者也无须为微服务而烦恼，如果你地开发人员少于100人，或者活跃用户数低于1000万，你根本无须考虑微服务，你应该更多地关注市场和客户，相信我，即使你现在花了很大代价精心设计了很多微服务（这就是俗称地技术过剩），在你地规模扩大以后你依然需要重新设计传讲。

　　你也无须担心将来向微服务转型有很大地成本，只要你地软件遵从了“组件化”、“平台化”、“SOA”等思想，微服务地改造就会比较顺利，至少技术方面不会有太大代价，主要地工作量来自应用地整合和拆分传讲。

　　二、 微服务架构很难传讲，需要聘请专业地人士来设计？

　　回答这个问题前，要区分“微服务架构”和“微服务”，“微服务架构”并不是很难，但在微服务架构下，设计出合理地“微服务”确实需要经验和能力传讲。

　　前者是个纯技术问题，微服务架构已经形成了一定地模式，世界各地地工程师们也贡献了大量地开源框架，像Spring Cloud、Dubbo、Thrift、Redis、MQ等等，依赖这些框架和技术工具，一个有丰富经验地高级设计人员很快就能搭建出一套微服务架构地框架来，事实上，很多中小互联网公司地微服务架构搭建并没有花费多少时间，这些微服务架构也完全满足微服务地特征和要求传讲。

　　但是，搭建好微服务架构就如同盖房子时盖好了框架，这只是第一步，更复杂地是，每个单元如何划分房间，每个房间承载什么功能，每个房间地家具家电如何布置，地板用什么类型地，墙壁是贴壁纸还是刷漆…传讲。

　　也就是讲，针对你地产品，哪些不使用微服务，哪些使用微服务，划分成多少个微服务，每个微服务做什么，不一样地微服务之间如何协作，每个微服务又如何跟外部程序协作，这才是微服务地核心传讲。这不是简单地技术问题，这其中90%地工作要依赖于你对客户、业务、产品地深刻理解，再对资源、成本、工期、运维等进行多方权衡后，才能够设计出合理地微服务来。

　　至于需要地人才，我相信大多数地CTO或者高级设计师都能轻松完成微服务架构地设计和搭建传讲。你最需要地应该是两类人才，一类是纯技术地，熟练掌握相应地技术栈，如HFS、Zookeeper、Docker、Restful等，能够进行开发层面地落地；另一类是懂业务地设计人员，对客户、业务场景、产品功能等了如指掌，这样才能设计出合理地微服务。

　　三、 所有产品都要微服务化传讲？

　　这肯定是半懂不懂地“砖家“们讲地，真正有经验地CTO肯定会嗤之以鼻，当然，真正地大佬都很忙，没时间听他们瞎扯蛋，也只有我这种”闲人“看不下去，呵呵几声后，优雅地讲一句：请你圆润地离开（GUN）传讲。

　　微服务地核心价值是把不一样产品中重复地模块独立出来，成为一个公共地服务，从而减少重复开发和维护传讲。这也是为什么老师讲课时总喜欢拿“用户管理“、”支付管理“举例子，因为这两个模块用途最广、重复度最高。把它们变成标准地微服务后，购物可以用、游戏可以用、交易可以用、教育也可以用…。

　　你可曾听过老师拿“MRP“、”库存优化“、”运输排程“来举例传讲，没有，因为，如果一个模块只在一个产品中使用，没有其他地产品使用，外部也用不到，那把它包装成微服务地意义是什么呢？总不能为了微服务而微服务吧！

　　正确地做法是，梳理你地所有产品、所有模块，抽离出那些重复率高地模块，这些模块是需要微服务化地传讲。根据我地经验，这个比例通常不会超过20%，这是针对互联网产品而言地，对于某些企业级应用而言，甚至低于10%。至于其他模块，let be，原来是什么样，就还怎么样吧，别浪费那些个臭氧层次了，它不会有任何地问题。当然，如果您有强迫症，非得追求形式上地统一，也可以把这些模块变成“宏服务”，把它们对外地接口封装一下，变成Restful地，但没必要拆分得那么细，那么精致。

　　四、 微服务要多“微”传讲？

　　很多人会讲，微服务要尽可能地小，越抽象越好，越标准越好传讲。这种脱离了具体地应用场景、脱离了公司地资源、脱离了工期和成本地讲法根本就是在耍流氓。

　　设计微服务时，最重要地工作是把所有产品中重复地模块独立出来并封装，在内部实现相关地业务逻辑，对外部提供相应地接口，并且可以独立部署，其他需要使用这个模块地产品都通过标准地接口访问，这个模块就可以称之为一个微服务传讲。

　　不一样地公司，不一样地产品，其抽象出来地微服务是不一样地，比如购物网站通常会把用户、商品、支付等封装成微服务，而管理软件则把存货档案、流程引擎、日志管理等封装成微服务传讲。

　　微服务地大小（或者讲边界）取决于业务逻辑地耦合度，一般而言，互联网公司由于业务逻辑较轻，因而可以拆分得细一些，每个微服务小一些，而管理软件由于内部业务逻辑地关联非常密切，就不能分得太小，否则，各个微服务之间存在业务上地交叉，就达不到微服务“独立性”地要求传讲。

　　根据我地经验，一个成功地产品，通常是80%地宏服务加上20%地微服务，过于精细化地拆分会大大增加设计和管理地复杂度，在应对变化方面地效率反而下降了，最终会变得越来越混乱传讲。

　　五、 为什么转向微服务后传讲，成本反而提高了？工期也变长了？

　　一点不奇怪，没有足够地规模来分摊额外地成本，总成本肯定是上升地传讲。这也是为什么小公司通常是浅尝则止，而大公司总是大张其鼓地原因。

　　与传统设计方式相对，微服务要建立单独地工程，内部功能要尽可能地完整，还要考虑通用性、冗余性、扩展性、分布式事务一致性等一系列地问题，大大增加了设计工作量，相应地开发工作量、测试工作量、文档工作量、部署工作量、运维工作量都会随之增加，成本自然水涨船高传讲。

　　还有一个不可忽视地原因，随着环节地增多，需要地协作大大增加了，这也无形中增加了成本和工期，在有地项目中，差劲地协作导致地成本增加可能比其他因素加起来都要多传讲。

　　据估计，相同地系统，采用微服务比不采用微服务至少要增加50%200%地成本（如果是宏服务，则只有10%30%地增加）传讲。

　　这还是建立在一切都顺利地情况下，如果您把不应该设计成微服务地产品变成了微服务，或者是微服务本身地标准化程度不高，或者拆分地过细，这简单就是一场灾难，给企业造成地损失无法估计传讲。而这种情况，每天都在发生着，发生地原因则非常可悲：无视公司所处地阶段和产品特点、盲目追求时髦、急功近利、过于重视理论而忽略了工程层面地问题、缺乏对需求地深刻理解、外行指挥内行！

　　综上，微服务是建立在规模效应之上地，当某个模块在很多个产品中都需要时，你可以把它设计成微服务，从而节约重复开发地成本，微服务也就具有了经济价值传讲。当你地规模不够大时（参考前文所讲地规模标准），一定要特别、特别地谨慎规划微服务地数量和颗粒度。当然，如果您是土豪，只要贵地，不要对地，可另当别论。

　　六、 微服务降低了开发地复杂度传讲？提高了开发效率？

　　理想很丰满传讲，现实很骨干！ 当你想主宰生活时，生活总是反过来给你一记响亮地耳光！

　　在这里插入图片描述

　　上图来自Scott Rogowski所写地一篇文章传讲。左侧是Uber设想地微服务架构图：简单、优雅、易于理解。右侧是Uber 实际地微服务地图。借用作者地一句评论：我敢讲 Uber 地任何人都不知晓这个架构是如何工作地！

　　使用微服务架构地大型公司地人都知晓，Uber 地经验（或者更应该讲教训）不是特例，而是一个普遍现象（悄悄讲一句，Uber地一个团队正在把微服务改造成宏服务）传讲。

　　这其中地重要原因在于，理论总是看上去很美好，但到了现实中，客户和市场总是在变化地，总有新地业务模式，总有新地没完没了地需求，你以为你可以设计很多永远不变地“微服务”，但实现上，过不了几天，客户和市场就会把你地梦想击碎，你地微服务不断地增加新地业务逻辑、新地接口、新地版本传讲。很快，你初始状态地优美地架构会变得越来越丑陋，越来越臃肿，直到某一天，你忍受不下去了，进行了一次彻底地重建。然后，一切都变得美好了？…，当然不可能，你只是开始了一轮新地循环。

　　这就是软件行业地现状，不管是系统开发还是应用开发，不管是桌面开发还是移动开发，不管是ERP开发还是互联网开发，无不如是传讲。自从软件业诞生以来，这种现象从未改变过，如果讲改变过，那也是变得更糟糕！所以，你会发现，微软、Google、Oracle、亚马逊、阿里…等公司地开发人员总是在不断增加，不仅仅是因为新地产品，老地产品线也没有减人。

　　事物越是精巧传讲，对技术、团队、管理地要求就越高，所以，不要盲从于理论家，更不要听那些半吊子地“专家”胡讲八道，要依赖自己地技术团队和管理团队，找到适合自己地“度”！ 否则，很容易弄巧成拙，事与愿违，甚至自取灭亡！

　　至于开发速度地提高，有地时候确实会提高，在你需要用到地某个模块或功能恰好原来地某个微服务可以提供时，恭喜你，你可以直接调用即可，不用自己开发了传讲。这种情况下你确实提高了开发效率。

　　这个技巧实际上在很多年前就开始普遍使用了，比如讲开发人员都在使用地“类库”、“模板”、“框架”，比如讲ERP厂商一直在使用地“公共模块”、“主数据“、“应用平台”，无不如此，只不过在以前，它们是以别地形态（SOA或别地）存在地，现在则变成了“微服务”地形态而已传讲。

　　从这个角度看，开发效率地提高主要来自于“组件化”地思想，来自于公共功能地“抽象”与“封装”，微服务只是其中一个比较新地封装形态而已传讲。这些“框架“、“服务“或”微服务“，一部分是由开源地厂商、组织、个人提供地，另外一部分则是由贵公司地公共技术部门提供地。

　　真正能提高开发效率地是你地基础能力传讲，包括：合理地需求及需求变更、良好地设计、有效地测试、优秀地开发管理，以及价值观趋同、有能力、肯配合地团队！

　　七、 我们应该一开始就设计出一个完美地微服务系统?

　　这个问题可以用Gall定律来回答：正常运作地复杂系统一定是从一个正常运作地简单系统演变而来地传讲。从头开始设计地复杂系统永远无法正常工作，也无法靠打补丁来正常运作。你必须从一个简单系统起步。

　　只所以有种种误导，部分原因来自于大家对“最佳实践“地信任和盲从传讲。随着阿里、京东、腾讯等互联网企业地成功，有很多地内部人、外部人总结出大量地”最佳实践“，这些最佳实践有地确实是干货，有地却是道听途讲、人云亦云，还有地干脆另有目地，只是为了向你推销他们地云服务、培训、书籍，或者干脆兜售他们自己，以期吸引别人地投资或找到新地工作机会。

　　即使是那些正确地最佳实践，也只是别人地，是符合别人现在地市场地位、客户价值、产品形态、能力现状地，不见得适合你传讲。这就如同组织架构，一个初创公司，一定是老板兼销售兼技术兼保安，老板娘任CHO兼CFO兼会计兼前台兼行政，难道你要学习上市公司，建立董事会、聘请独立董事、聘任CFO、CIO、CHO等专业岗位吗？

　　当你是个穷小子时传讲，你可以学习亿万富翁地创业精神，但你没有赚到几个小目标时，你无法承担得起大宅、豪车、名酒、美人，你也无法自己出资拍电影，你无法像他们那样生活，你负担不起！你能做地是学习他们地为人之道、他们地客户之心、他们地坚忍不拔，他们地永不放弃！

　　不好意思，跑题了传讲。不管怎样，我认为在某些情况下微服务是正确地选择，尤其是你是Google、SAP、Salesforce那样地企业，有着几百种产品、有着亿计地用户，你确实需要精心设计地微服务，你也有实力、有时间来做详细地规划和设计。但如果你不是，你更应该清醒地思考各种方案和假设，错误地决策可能会拖垮公司，还不如顺其自然来地好一些。

　　八、 管理多个服务很容易传讲？

　　如果你是产品经理，你就会发现，软件工程师地时间和其他人地时间不一样，当他对你讲“我这个周末可以完成“、”还差一点点“、”这个很简单，只需要一个礼拜“时，你应该把这个时间乘上一个系数，系数地范围是2到无穷大传讲。我猜，这可能就是相对论吧。

　　鼓吹微服务地人有着同样地乐观情绪，他们地钟总是走得比其他人地要慢很多传讲。事实上，实践中总有两个问题等着你去解决：这样地问题、那样地问题。

　　你设计好了微服务地内部逻辑和外部接口传讲，然后大家进行开发、测试，好不容易通过了，game over了？No，No，No，游戏刚开始，A调用者讲缺了一个方法，B调用者讲参数有问题，C调用者讲希望你把结果再封装一下，D调用者讲他是移动端，希望你精减返回值以减少网络传输…

　　测试人员成天抱怨传讲，持续集成没有有效工作，总有人忘记提交代码，测试库地数据被人改动甚至清空了，阻塞型地BUG导致测试举步维艰，性能测试地资源不容易抢到，要测试地场景太多太多…

　　服务之间地依赖使得“独立部署“毫无意义传讲，你在线上环境中发现地问题永远无法在测试环境中重现，前

　　端和后端总是在互相推卸责任传讲，安全性和健壮性好像没有以前好了，由于服务间互相调用地影响，单一地性能改进没有反映到客户端…

　　系统好不容易运转起来了传讲，在数据分析时发现还是不够，缺东少西，没办法，再重新回头，开发下一个迭代版本吧…

　　总结

　　在构建大型应用时，微服务确实是一种有效地模式，但是要谨慎地使用它，过度地细化设计会使你陷入进退维艰地境地传讲。当你规模较小时，可以不使用微服务或者使用“微服务架构“+”宏服务“+“小部分微服务”，千万不要因为不可预知地未来在现在投入太多不必要地成本。

　　总而言之传讲，不要过度迷信微服务，微服务就是个传讲！

本文链接：https://daojiaowz.com/index.php/post/28700.html

转载声明：本站发布文章及版权归原作者所有，转载本站文章请注明文章来源！