-
站在系统整体的角度考虑问题;不仅要从技术的角度考虑问题,也要从业务的角度来考虑问题,深入理解系统的挑战在哪;做好各方面的平衡,在各项资源的约束下,寻求一个最优解。
-
架构的出发点是业务和技术在不断复杂化,引起系统混乱,需要通过架构来保证有序。
-
架构实现从无序到有序,是通过合理的内部编排实现的,基本的手段,就是“分”与“合”,先把系统打散,然后将它们重新组合,形成更合理的关系。
-
“分”就是把系统拆分为各个子系统、模块、组件。
-
“合”就是基于业务流程和技术手段,把各个组件有机整合在一起。
-
-
业务架构、系统架构、技术架构
-
业务架构就是讲清楚核心业务的处理过程,定义各个业务模块的相互关系,它从概念层面帮助我们理解系统面临哪些问题以及如何处理;
-
应用架构就是讲清楚系统内部是怎么组织的,有哪些应用,相互间是怎么调用的,它从逻辑层面帮助我们理解系统内部是如何分工与协作的。
-
技术架构就是讲清楚系统由哪些硬件、操作系统和中间件组成,它们是如何和我们开发的应用一起配合,应对各种异常情况,保持系统的稳定可用。所以,技术架构从物理层面帮助我们理解系统是如何构造的,以及如何解决稳定性的问题。
-
-
一个好的架构设计既要满足业务的可扩展、可复用;也要满足系统的高可用、高性能和可伸缩,并尽量采用低成本的方式落地。所以,对架构设计来说,技术和业务两手都要抓,两手都要硬。
-
产品经理是站在用户的角度进行需求分析,而业务架构师是站在开发者的角度定义系统内部结构。
-
业务架构扩展性的本质是:通过构建合理的模块体系,有效地控制系统复杂度,最小化业务变化引起的系统调整。
-
通过拆分,实现模块划分(水平拆分-按功能、垂直拆分-按业务);通过整合,优化模块依赖关系(通用化、平台化)。
-
通过模块通用化,模块的数量减少了,模块的定位更清晰,概念更完整,职责更聚焦。在实践中,当不同业务线对某个功能需求比较类似时,我们经常会使用这个手段。
-
业务平台化是模块依赖关系层次化的一个特例,只是它偏向于基础能力,在实践中,当业务线很多,业务规则很复杂时,我们经常把底层业务能力抽取出来,进行平台化处理。
-
-
微服务是去中心化的,不需要SOA架构中ESB的集中管理方式。在实践中,我们往往弱化微服务的小应用定位,然后扩大化微服务小服务的定位,我们不再强调端到端的业务封装,而是可以有各种类型的微服务。我们需要对服务依赖关系进行有效的管理,打造一个有序的微服务体系。否则的话,东一个服务,西一个服务,