<h2>什么是“分而治之”</h2>    <p>面对业务功能复杂的企业级软件，我们一般都会寻找各种方式或者是标准进行抽象、进而将业务拆分或组合，从而达到分而治之的目的。</p>    <p>JAVA很早就有模块化的概念，也就是OSGi，在我看来，他应该可以算是微服务化的一个非常早期的表现形式了。OSGi联盟进行管理的标准规范，就好比是如今各微服务间传递数据的协议约定。而一个个bundle，就好比是一个个独立部署的服务。他的bundle管理，以及相互之间的依赖关系，就如同各个单独部署的微服务之间的链路监控。只不过微服务是独立部署的，有独立的JVM容器，独立的硬件环境，通信是需要经过网络传输的。而OSGi不是，它是运行再同一个JVM下面下的，数据交互是在同一个进程内部。</p>    <p>但是，上面的内容并不重要，本文也不是重点要去讲OSGi或者是微服务的实现，回归正题，我们还是来讨论一下，如何去进行一个业务项目进行分解、架构，从而实现分而治之。</p>    <h2>如何去定义架构</h2>    <p>关于架构，有非常多的定义。百度的描述如下：软件架构（software architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。 软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。来自ANSI/IEEE Std 1471-2000的定义如下：架构是一个系统的基本组织，通过组件、组件之间和组件与环境之间的关系以及管理其设计和演变的原则的具体体现。</p>    <p>简单的说，架构就是一系列的决策，这些决策设计软件系统的组织、组成系统之间的协作方式。</p>    <p>架构，没有固定的风格，也没有一招鲜走遍天的模式，所谓的架构，应该是自上而下的，不仅要关注高层的服务，还要关注中间的模块甚至是底层的代码。作为架构师，相对于开发人员，其更有价值的应该是在于他的广度和抽象能力，而并非其在某个业务的深度，作为该角色所要去突破的，也并非是去做广度基础上的深度，而应该是尽可能的提升有效的交流，将高层次的理念转化为具体的实现，从而和具体的开发人员在系统的设计上达成“共识”，尤其是在各组件之间的交互问题上、边界划分上，更是应该早早地达成共识。</p>    <p>以下是一张架构师和开发团队在软件作业中的关系图。 <img src="https://simg.open-open.com/show/7809d475812caeba65d3ee916ffda4f0.png"></p>    <h2>架构的目标是什么</h2>    <p>架构的目标，简单的说就是消除架构，在灵活性和复杂度之间取得一个平衡点，从而使变化所带来的影响和成本都有所降低。而最好的方式，就是将大型的系统进行业务分析，识别接缝，定义边界，进而组件化、模块化、服务化，最终分而治之。</p>    <h2>架构分解的案例</h2>    <p>大型项目中，模块之间的耦合是无可避免的，因为总是有一些业务需要模块间的相互合作来完成。但是模块间的循环依赖，是需要在架构阶段去尽可能的避免的，尤其是在复杂场景中存在的多个模块之间的间接循环关系。如果不消除这种循环依赖关系，那么就很难去做到服务化的分而治之。</p>    <p>比如有一个面向车商服务的项目，里面有涉及到人、车、订单的关系，从现实场景来说，他们是一个两两双向关联的关系：订单包含了车、买家、卖家，车包含了订单和车主，人包含了成交的订单和拥有的车。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/90f7d106ea68a1dffbd08a2a9b0b01c1.png"></p>    <p>那么，如何去化解呢？ 我们可以做业务上移，也可以做服务下沉。</p>    <p style="text-align: center;">上移：是将导致依赖的成因上移到一个更高等级的模块中去，从而消除双向依赖，变成自上而下的单向模式，上移后如下： <img src="https://simg.open-open.com/show/b27aafdca18fc16547f7ba96baef7e91.png"></p>    <p>下沉：是将导致依赖的成因放到一个较低等级的模块中去，如下： <img src="https://simg.open-open.com/show/52e30a799bf16676d11694b63d5643e1.png"> 如此，我们就将人、车和订单之间的关系进行了原则性上的解耦。解除了原有的依赖关系。但业务依旧是以一个项目在对外提供服务的。</p>    <p>后续随着业务的扩大，可能人、车、订单又各自孵化出很多的自有的业务逻辑，项目体量越来越大，投入进来的人也越来越多。每次的业务调整、项目上线都会让工程师们胆战心惊，生怕牵一发而动全身。</p>    <p>这个时候，其实不管是上移式的还是下沉的方案，都可以轻松将这三个业务独立成单独的项目，安排合适数量的工程师去独立维护，而对外只是暴露服务化的接口而已。至于最终是选择上移还是下沉，这就要看具体的业务场景了。以下面分别是针对上移和下沉的两种情况的拆分： <img src="https://simg.open-open.com/show/e8ba4d43ddbc8cf802912fdf0ce298e4.png"> <img src="https://simg.open-open.com/show/df2e466c175acb2fe5972ad0d1952037.png"> 再后来，随着业务数据越来越多，对于每个业务小组来说，既维护上层业务，又维护基础数据之间的存储关系、业务关联、分库分表等等，可能就会出现有些力不从心了，而且不同的小组之间，对于基础数据的抽象化层面来看，也很难去做到全局的统一。所以这个时候，就需要从上一步拆离的项目中，抽象出共同的一部分来进行统一维护和对外提供服务。 <img src="https://simg.open-open.com/show/7c03701e1805d8fc298dd209ee4b3205.png"> 最后，当单个基础服务也承载不了的时候，那就再开始拆分。</p>    <h2>总结</h2>    <p>总之呢，没有固定不变的架构模式，也没有“银弹”一说，架构的规划和手法始终是需要随着业务的发展而变化的（并非每次都是加中间层、代理层，或是一味的拆分而不考虑到合，因为多出来的模块都是需要额外的维护投入），努力在复杂度和灵活度之间做取舍和平衡，最终将项目控制在一个能高效产出又可维护的规模状态。</p>    <p>不过，每一次的重构、每一次的拆分和合并，可以选择的手段和方法却非常之多，这需要架构师们根据当前业务的发展趋势做一个判断，从而去做稍微长远一些的准备，比如一年，甚至两年，而再远就应该没什么必要了，很有可能会导致过度设计，最终得不偿失。</p>    <p> </p>    <p>来自：https://blog.souche.com/jia-gou-de-fen-er-zhi-zhi/</p>    <p> </p>