如何设计一个架构

正文

请到「今天看啥」查看全文

应用的分偏向于业务，反映业务架构，应用的合偏向于技术，影响技术架构。分降低了业务复杂度，系统更有序，合增加了技术复杂度，系统更无序。

应用架构的本质是通过系统拆分，平衡业务和技术复杂性，保证系统形散神不散。

分久必合，合久必分，结合当前的实际资源情况做出最终的决策，这是整个过程中最耗时的点，它决定着架构的复杂度和开发成本。方式上包括但不限于抽出可重用的功能、功能的组合、拆分粒度更细的功能提高可重用性等等。这一切的决策都要以“恰到好处”为宜。千万不要盲目的跟从微服务之风！千万不要盲目的跟从微服务之风！千万不要盲目的跟从微服务之风！重要的事情说3遍。服务粒度越细，调用链路越复杂，带来的开发成本是否适合团队，是作为一个架构师需要着重考量的点。

系统采用什么样的应用架构，受业务复杂性影响，包括企业发展阶段和业务特点；同时受技术复杂性影响，包括IT技术发展阶段和内部技术人员水平。业务复杂性（包括业务量大）必然带来技术复杂性，应用架构目标是解决业务复杂性的同时，避免技术太复杂，确保业务架构落地。

3、技术架构: 技术调研, 确定系统核心技术点

1、技术选型:  根据业务场景, 了解业内的玩法，能不能解决现有问题.  比如使用微服务构建,dubbo,spring cloud.

2、评估技术成本: 结合业内的玩法与自有技术体系的结合成本，评估使用成本，推广成本.

例如要使用dubbo,评估现有开发人员能不能hold住,  重构成本有多大.

3、方案取舍: 技术方案有多种，了解每种方案优缺点, 让大家参与讨论.

4、确定系统核心技术方案:

技术架构最终是确定组成应用系统的实际运行组件（lvs，nginx，tomcat等），这些运行组件之间的关系，以及部署到硬件的策略。

技术架构还要考虑系统的非功能性特征，对系统的高可用、高性能、扩展、安全、伸缩性、简洁等做系统级的把握。

系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这也是架构设计工作中最为困难的工作。

4、数据架构:

数据架构指导数据库的设计

5、架构总览图:

架构综览图,

这样能够帮助站在一个更高的角度去考虑架构的演变问题。如果是针对现存项目重新做架构，那么需要把现有项目架构梳理出来，作为我们上面思考过程中的一部分参考信息。

请到「今天看啥」查看全文