共计 2607 个字符，预计需要花费 7 分钟才能阅读完成。
最近牵头在梳理部门的零碎架构合理性，开始工作之前，我首先想到的是如何定义架构合理性？
从研发的角度来看如果零碎上下文清晰、利用架构设计简略、利用拆分正当应该称之为架构正当。
基于以上的定义能够从以下三个方面来梳理评估：
1、零碎的上下文清晰：明确的晓得和四周零碎的调用关系，数据同步机制；
2、利用架构设计简略：架构分层正当，功能定位清晰，不会呈现性能边界之外事件；
3、利用拆分正当：零碎内的利用粒度在一个正当的范畴内；利用间调用链路不应过长。
零碎的上下文清晰
零碎上下文图一词最早是从 Simon Brown 的 C4 模型中借用而来的，该模型”通过在不同的抽象层次从新定义方框和虚线来形象表白架构的含意“。
C4 模型把零碎分为四层，每层都代表着不同的视图架构，关注点不同。第一层，讲的零碎上下文，零碎高层次的形象。
如下图显示集体银行账号在浏览账户过程中产生不同的零碎之间交互。如果把 Internet Banking Sysytem 当成咱们的指标零碎，那么 E -mail System、MarinFrame Banking Sytem 就是它的伴生零碎，也能够称为内部零碎，它给 Internet Banking Sysytem 提供零碎价值，属于零碎外，是黑盒。
零碎上下文明确了指标零碎和内部零碎的关系，它和内部零碎一起给指标用户提供价值。绘制零碎上下文的时候，须要留神指标零碎和内部零碎之间的依赖方向。北向依赖意味着内部零碎调用指标零碎的服务，须要思考指标零碎定义了什么样的服务契约；南向依赖意味着指标零碎调用了内部零碎的的服务，须要理解内部零碎的接口、调用形式，通信机制，甚至当内部零碎呈现故障时，指标零碎该如何解决。
除了参考以上的画法，也能够用业务序列图示意。它脱胎与 UML 的序列图。序列图能够从左侧的角色开始，体现消息传递的秩序。这隐含这一种驱动力：咱们从左侧的参加对象开始，寻找与之合作的执行步骤，而后层层传进地推导出整个残缺的合作流程。
企业序列图，代表了企业级零碎的形象，指标零碎和内部零碎之间的协作关系，参加的零碎是一个残缺的整体，所以不须要也不应该参加零碎的外部实现的细节，音讯的方向更多的代表零碎的责任。业务序列图如下所示：
利用架构设计简略
利用自身是有架构分层的，Martin Fowler 在《企业应用架构模式》提出正当的零碎分层应该包含体现层，畛域逻辑层，数据源层。体现层次要提供服务，解决用户申请。畛域层是解决逻辑，是零碎的外围。数据源层与数据层、音讯零碎，与其余软件包通信。
后续倒退的畛域驱动架构设计，演变成四层，在体现层下退出了应用层，同时把数据源层改为基础设施层，冲破了数据库管理系统的限度。
基于以上的零碎分层，无论你是采纳的三层架构还是四层架构，利用代表着性能边界，提供那些外围的能力，能做那些事件，那些事件不能做。
一个好的实践经验是参考畛域驱动设计的业务域的方法论，梳理好零碎的一二三级域，最多不超过四级，做好各级域的定义。好的域的定义代表着零碎能力的边界，让你明确那些事件能做，那些事件不能做。
基于以上梳理好的零碎业务域的定义和能力边界，咱们在梳理的时候通常会两类零碎，第一类是现有存量的零碎且需要迭代绝对频繁的零碎，这类零碎要害是要梳理出有哪些外围的能力，是否在上述零碎的域的定义范畴内的，是否其余零碎有相似的能力，如果有的话，须要思考合并。另外还须要思考外围能力公开化、文档化，至多让部门内晓得，有地可查，防止零碎的反复造轮子。
遇到第二类零碎是存量零碎且没有需要迭代，业务上根本没有调用量的。这类零碎须要和业务沟通是否有下线打算，是否有相似的零碎能够代替，给业务决策提供技术参考。
利用拆分正当
需要开发中，一个我的项目或者需要的实现可能须要多个指标零碎协同来实现，这波及到指标零碎的拆分的粒度，零碎拆分成利用的粒度没有统一标准，然而要在绝对正当范畴内，能够参考的因素包含业务布局，零碎调用量级，基于业务布局的架构设计，部门内的人数及分工。过多过少都是不好的。
如果一个新业务短期内看不到大的倒退，在初步布局利用的时候，能够先粗粒度拆分，部门内人数均匀不能应该超过 2 - 3 个利用，再多必然面临着一个需要实现的时候不同零碎的切换老本。如果后续业务倒退起来，部门内人数增多，因为分工更精密，能够思考更细粒度的拆分，零碎拆分必然会带来另一个问题，零碎之间该如何的协同以及零碎的调用链路的长度。
基于以上讲的零碎分层的概念，部门内零碎能够分为两类，一类零碎是业务网关，一类是通用的业务能力。业务网关面向用户，用来协同利用的流动，不蕴含业务逻辑，不保留业务对象的状态，相当于畛域驱动设计应用层 + 体现层，有人称作它为业务 SOA，或者 BFF 层。
通用业务能力相当于畛域逻辑层 + 基础设施层，作为软件的外围所在，保留了业务对象的状态，对业务对象的长久化被委托给基础设施层，基础设施层作为其余层的撑持层，实现了和其余零碎的通信，实现业务对象的长久化。
在以上两类零碎中，业务网关是依赖通用业务能力层，业务网关是北向依赖，通用业务能力层是南向依赖。在一个性能的实现不倡议链路长度不超过 2。同时也要留神到零碎之间相互依赖的状况，要器重，此点是零碎稳定性的危险点。
老本量化：
基于以上三方面剖析，梳理出的交付物:1、零碎的上下文依赖；2、零碎的业务域定义及能力规划地图。3、利用调用链路的长度及互相的依赖关系；4、利用拆分粒度合理性的评估；5、零碎中能力的下沉或者合并；6、业务量少的零碎列表。
其中 1 -4，能够看作零碎的行动指南或者准则，5- 6 是下一步的口头，更简略的说是咱们常做的零碎的关停并转。在业务部门零碎关停并转还须要思考到老本问题，做好老本的量化。
首先须要评估关停并转的付出的老本，其次要评估零碎日常保护 1 - 3 年的老本包含人力老本和机器资源的老本，前者和后者的三年累计值相减，如果大于零，零碎倡议临时不动，如果少于零，能够思考关停并转的打算。
以上是我从研发角度零碎架构合理性的思考。
架构合理性如果从业务角度来评估，可能就变成以下三个方面：一是能解决当下业务需要和问题。2、高效实现业务需要: 能以优雅且可复用的形式解决当下所有业务问题。3、前瞻性设计: 能在将来一段时间都能以第 2 种形式满足业务，从而不会每次当业务进行演变时，导致架构天翻地覆的变动。
视角的不同必然代表着大家对同一件事件的认识不同。
作者：京东批发 高田林
起源：京东云开发社区 转载请注明起源