收录于话题
#程序员
33个内容
这里是Z哥的个人公众号
每周五11：45 按时送达
当然了，也会时不时加个餐～
我的第「135」篇原创敬上
这次分享给大家的是一篇与技术相关的文章，但是我想表达的核心观点并不仅限于技术范围。很多事物的发展都逃不开这个规律。如今，这件事也正在分布式、微服务概念大行其道的软件开发领域里发生。就在这个月5号，在近些年大热的Service Mesh中被热炒的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.
不知道你是怎么看待「单应用模块化」和「分布式服务化」两者的利弊的呢？欢迎留言给我一起讨论哦。
推荐阅读：
原创不易，如果你觉得这篇文章还不错，就「在看」或者「分享」一下吧。鼓励我的创作 ：）
如果你有关于软件架构、分布式系统、产品、运营的困惑
可以试试点击「阅读原文」