网站在线问答怎么做,北京海淀区制药企业,h5长页面怎么制作,wordpress设置页面缓存大家好#xff0c;我是Z哥。这次分享给大家的是一篇与技术相关的文章#xff0c;但是我想表达的核心观点并不仅限于技术范围。我们中国有句古话#xff0c;分久必合#xff0c;合久必分。很多事物的发展都逃不开这个规律。如今#xff0c;这件事也正在分布式、微服务概念大… 大家好我是Z哥。这次分享给大家的是一篇与技术相关的文章但是我想表达的核心观点并不仅限于技术范围。我们中国有句古话分久必合合久必分。很多事物的发展都逃不开这个规律。如今这件事也正在分布式、微服务概念大行其道的软件开发领域里发生。就在这个月5号在近些年大热的Service Mesh中被热炒的istio宣布回归到单体应用架构。可能有的人对istio不是很了解我稍作下介绍。istio是一种以sidecar模式为应用程序建立网络通信的技术框架基于其搭建的通信网络具有负载均衡、服务间认证、监控等功能。这些功能都是微服务系统中必不可少的。它亮点就在sidecar模式的无代码侵入上配合上“黄金搭档”——docker让它成为了近两年火热的Service Mesh概念的带头大哥之一。这个框架的设计非常整洁各个模块的职责清晰被不少人视作“高内聚、低耦合”的范本。但是它的每个模块都是单独维护的其中Mixer的模块甚至是单独一个进程来运行。就这些简单的分离其实也是“分布式”、“微服务”的「分治」思想的体现。此时作为Service Mesh的领头羊宣布回归单体应用虽然对它自身来说只是一个架构调整而已但间接给国内各种炒作微服务概念的人敲了一下警钟。身边有不少人或者企业其实在盲目的追求微服务架构觉得少了这个就不好意思说自己在互联网企业做技术一样。并且有一些还在追求更细粒度的微服务拆分上乐此不疲。原本一个应用程序就能搞定的一件事非得拆成4个、5个程序相互协调才能完成。这样真的划算吗要打上一个大大的问号。其实类似这样的事情在我们的生活中很常见但是在生活中我们却理性得多。想象一下假如现在你要去倒垃圾那么需要做以下这几件事。换上衣服、给垃圾分类、下楼走到垃圾桶前倒掉。你会请3个人分别帮你换衣服、做垃圾分类以及下楼去倒掉吗我想肯定不会这不是搞笑么。别笑过度的服务化拆分就是这么变扭的一件事。一个叫ChangeClothesService、一个叫WasteSortingService一个叫DumpRubbishService……那么如何判断当下的系统是否过度拆分你可以试着回答以下几个问题。各个部分是否支持单独部署和更新如果不能就是过度拆分。是否可以由不同的开发人员维护不同的部分如果不能就是过度拆分。是否存在不同的运维策略。比如不同的安全策略、部署策略等。如果不存在可能是过度拆分。是否经常费很大劲才能确定问题的根源在哪一个服务上如果是可能是过度拆分。当然拆分的好处是显而易见的分而治之成就“高内聚、低耦合”的终极目标。但其实单体应用做好模块化划分和管理也能成就“高内聚、低耦合”这个目标同样不会成为“Mud Ball”。不过为了在同一个项目里达到“高内聚、低耦合”的效果这必然会比使用服务化的拆分方式付出更多的代码管理成本。毕竟后者对代码进行了硬性的隔离而单体应用的模块化拆分全靠每一位参与编码的程序员是否共同遵守了一些共识。比如我们在编码的时候要尽可能的共同遵守以下这些原则单一职责原则里氏替换原则依赖倒置原则迪米特法则开闭原则接口隔离原则合成复用原则为了确保大家遵守统一的规则对codereview的要求就会提高所以代码管理成本是实实在在会增加的。但是这些额外的成本相比过度微服务化后增加的复杂度所带来的隐性成本哪个划算还真得好好算算。istio团队已经深刻认识到了这个问题所以他们喊出了一个口号Complexity is the root of all evil or: How I Learned to Stop Worrying and Love the Monolith.不知道你是怎么看待「单应用模块化」和「分布式服务化」两者的利弊的呢欢迎留言给我一起讨论哦。推荐阅读聊聊面试的事应聘方新的一年程序员如何让自己更值钱原创不易如果你觉得这篇文章还不错就「在看」或者「分享」一下吧。鼓励我的创作 如果你有关于软件架构、分布式系统、产品、运营的困惑可以试试点击「阅读原文」
