网站开发现状,wordpress 图片 宽 高,在哪里可以看免费的资源,WordPress点击弹出评论大家好#xff0c;我是Z哥。不管是十几年前 SOA 的流行#xff0c;还是 7、8 年前微服务的大行其道#xff0c;还是如今云原生的展露锋芒#xff0c;背后都离不开一件事#xff0c;程序拆分或者说服务拆分。否则#xff0c;一个单体应用#xff0c;以上的这些技术潮流好… 大家好我是Z哥。不管是十几年前 SOA 的流行还是 7、8 年前微服务的大行其道还是如今云原生的展露锋芒背后都离不开一件事程序拆分或者说服务拆分。否则一个单体应用以上的这些技术潮流好像都与它没什么关系只是一个看客。虽然Z哥我没有从头开始完整地亲历过以上三个时期但是这三个时期都有过我留下的足迹。所以我想我接下去分享的内容应该对处在云原生时代的大家有所帮助。/01 拆分有什么好处/拆分的目的很容易理解分而治之。本质是将复杂的大问题分解成更简单的多个小问题从而解决它。而在拆分之前的单体系统中我们往往面临着哪些问题呢01 数据库瓶颈所有的业务都由一个数据库承载着随着业务的发展数据库日常内存吃紧时不时还搞出个 cpu 90% 以示它的怒火。02 增加人员对开发效率提升的边际效益递减项目里的代码量从 10 万行增长到 100 万再到 1000 万。随着代码量的增加代码之间的耦合问题越发严重开发效率明显降低。好吧效率不够数量来凑。扩招了更多的人进来但是发现耦合问题更加严重了经常出现 A 等 B 提交代码B等 C 提交代码C 等 A 提交代码的情况……03 运维成本指数级增加随着项目参与人员的增加每天发布程序的次数也增加了。可怕的是代码量也在增加导致每次编译发布的时间也增加了这对开发效率来说是双重打击。每天发布的时间加起来可能就占了半天。希望你所在的团队不要处在如此痛苦的场景中。/02 什么时候拆/拆分虽好但也不是万能的灵丹妙药。对于大多数组织来说一个新系统不适合一上来就按照拆分的思路来做。因为拆分需要基于对当前业务、当前系统、当前环境的理解之上的而面对一个未来充满未知的新业务我们当下的信息积累是不够的如果过早拆分很容易导致边界划分不合理的情况这在后续会带来不小的负面作用。甚至可能这个产品在经过市场验证失败后就被砍了之前的工作做得再多、再完美全白费了。因此相对来说从一个已有的单体系统中逐步拆分出一个个模块反而容易得多因为确定性更高。单体系统和分布式系统对成本与业务复杂度之间的关系是这样的。因此在这个临界点附近进行拆分工作的性价比是最高的。对于如何判断是否达到了这个临界点我认为至少要符合以下三点中的两点。业务已在市场站稳脚跟规划中业务发展速度未来可能会加速。开发人员持续扩张并且未来还将继续。平均单人开发效率下降。多个开发人员之间的工作相互影响、依赖导致解决这些冲突所花费的成本占到了总开发成本的 30%以上。比如提交的代码冲突、你等我 coding 完才能继续 coding 这种往往这样的情况下每个迭代的版本也很大。/03 拆分前的准备工作/并不是以上条件满足了就可以拆了。在实际拆分之前我们要做一些准备工作。这其中最为关键的是两件事统一拆分原则基础设施建设因为从单体系统到分布式系统不仅仅是技术的升级更是开发理念的转变。这两件事的具体就不展开了前人已经总结过很多了我就简单罗列一下。在应用拆分这件事上比较适用的是高内聚低耦合闭包原则接口隔离演进思维避免循环依赖另外分布式系统中常用的基础设施主要是以下这些消息队列缓存日志系统服务治理监控网关配置中心数据访问组件以上这些是必须项其它可选项还有不少比如分布式文件系统、容器管理平台、CI/CD 等等。/04 拆分思路/具体的拆分其实就是划分边界的过程。强烈建议通过 DDD 的思想进行。深入理解业务从中定义出隐含的实体、值对象。从实体对象中找出聚合根根据实体、值对象与聚合根的依赖关系建立聚合。根据业务场景等环境因素划分限界上下文。这里的限界上下文就可以与拆分出来的微服务一一对应。其中最关键的是「抽象」工作为了更易理解还是来举个例子说一下。比如当我们在某某养车平台下单一个保养订单你说其中的“安装”业务该以什么形式进行交易比较合理Z哥我认为是将其当作一个普通商品看待当然该平台也的确是这么做的。如此一来购买机油机滤和安装服务对用户来说是一样的很自然地被创建在一笔订单里而不是两笔订单。如何评估抽象的好不好呢可以从以下两个角度来观察。两个限界上下文之间的依赖应该越少越好。并且依赖的上游不需要知道下游的信息。比如订单 service 依赖商品 service 但是商品 service 无需知道订单 service 的存在。推演可能的未来业务如果能响应业务变化不一定 100%满足则证明该抽象是符合未来预期的可以在一段时间内支撑业务的持续发展。不过不管怎样最终你都在抽象程度、成本、复用性这三者之间平衡。除此之外我们还可以根据以下三个维度来进行拆分。是否经常变动复用程度的高低是否有特殊的要求高性能、安全性等好了总结一下。这篇呢Z哥和你分享了我对微服务或者说分布式系统如何拆分的看法。拆分可以解决单体系统的三个痛点。数据库瓶颈。增加人员对开发效率提升的边际效益递减运维成本指数级增加。但是拆分也不是越早越好至少符合以下三点中的两点。业务已在市场站稳脚跟规划中业务发展速度未来可能会加速。开发人员持续扩张并且未来还将继续。平均单人开发效率下降。多个开发人员之间的工作相互影响、依赖导致解决这些冲突所花费的成本占到了总开发成本的 30%以上。比如提交的代码冲突、你等我 coding 完才能继续 coding 这种往往这样的情况下每个迭代的版本颗粒度不得不变得很大。然后拆分前还需要做好两项准备工作。统一拆分原则基础设施建设具体实施拆分的思路建议以 DDD 的思想来进行。其实任何事都没有一招鲜吃遍天的方法随着业务、技术的发展我们的拆分思路也需要持续迭代。如果你之前这方面的实战经验比较缺乏不妨从我分享的这些方面入手试试希望能对你有所帮助。推荐阅读接手历史悠久的老项目干or跑如何让自己更自律原创不易如果你觉得这篇文章还不错就「点赞」或者「在看」一下吧鼓励我的创作 也可以分享我的公众号名片给有需要的朋友们。如果你有关于软件架构、分布式系统、产品、运营的困惑可以试试点击「阅读原文」
