标签：架构设计 架构 预测 可用 复杂度 任务分配 笔记 提炼

1.什么是架构?

架构是软件开发早期一项重要的决策，这个决策可以帮助软件工程确定思路，减少复杂度，尽可能的贴近用户需求。

2.架构设计的目的?

1.不能为了架构而架构。

2.架构的目的是为了解决软件系统复杂度带来的问题，是降低软件的复杂度的一种解决方案。

3.架构的复杂性体现在那些方面？

A.高性能需要带来的复杂度：

1.主要有为了高性能单台服务器内部的复杂度；以及为了高性能多台服务器集群带来的复杂度。

2.单机复杂度主要体现为：多线程和多进程。操作系统调度的最小单位是线程，操作系统分配资源的最小单位是进程。进程间通讯的方法有：管道、消息队列、信号量、共享存储。完成一个高性能的软件系统，需要考虑如多进程、多线程、进程间通、多线程并发等，这些技术并不是最新的就是最好的，也不是非此即彼的选择。

3.集群的复杂度主要体现为：任务分配和任务分解。任务分配主要指在不优化拆分任务的前提下，粗暴的增加机器，以提高性能的方法。任务分解主要指在将大任务进一步细分，得到子任务或者叫子系统，进而更进一步优化这些子系统，并将大任务分配到不同的机器上提高性能的方法。集群不是越多越好，机器越多，复杂度越高（任务分配和状态保持的难度和复杂度越来越高），提升效率越低（考虑到网络损耗和机器本身的损耗）

B.高可用带来的复杂度：

1.高可用的定义为无中断，无中断的主要实现途径是冗余。一般体现为计算高可用和存储高可用

2.计算高可用的复杂度主要体现在任务分配算法的复杂和任务分配服务器的选择。

3.存储高可用的复杂度主要体现在规避数据不一致的问题。

4.高可用的本质，是系统判断出现故障，并通过决策采取一定的措施，进入对应处理，保证高可用。但是通过冗余来实现的高可用，决策系统不能本质上无法保证完全的正确。有集中常见的决策方式：独裁式——只有一个决策者，但是它的风险在于决策者服务器本身故障，协商式——两个决策者，最常见的有主备决策，它的分线是如果两个决策者之间的连接中断，民主式——多个独立的个体投票产生决策者，多数取胜，他的风险在于设计复杂，且可能出现因为链接中断产生多个票选结果（脑裂）

C.可扩展性带来的复杂度：

1.可扩展性代表着架构设计可以完美的预测变化，完美的封装变化，这两个都很困难。

2.预测变化的复杂度主要有：没能每个点都做预测，不能完全不做预测，预测可能存在错误。

3.封装变化的主要方法有：封装变化层（三层模式，防腐层都是这个意思），这种方法的复杂度主要体现在层与层之间如何拆分？层与层之间的接口如何定义。第二种办法是将代码提炼出抽象层和实现层（面向对象，设计模式都是这个意思）它的复杂度主要是：面向对象和设计模式都非常复杂，学习成本高

4架构设计这么难，要考虑这么多，到底应该怎么做?

架构设计的三大原则

1.合适自己优于业界领先。有多少人，有多少时间做多少事，强行要求领先、先进，不顾及自己已有的积累，资源和业务场景，会造成迟迟不能落地，水土不服，最终失败。大公司的业界领先方案是在自己的业务领域多年深耕，花费了大量的人力物力，不断的演化发展最终得到的。

2.不断演进优于一步到位。软件的不断变化特性决定了这一点。再完美的架构不做改变也最终无法适应业务的发展。要求一步到位是风险巨大且浪费资源的。只有不断的迭代，保留优秀的设计，修复有缺陷的设计，改正错误的设计，去掉无用的设计，才能最终成为一个有用的设计。

3.简单优于复杂。无论是结构的复杂还是逻辑的复杂都会存在各种问题，如果一个需求简单方案和复杂方案都能实现，那么一定要选择简单方案。（目前政务系统的存在逻辑复杂的问题）。

4.合适自己>简单>不断演化。优先考虑自己的业务需要，挑选简单方案快速落地验证，适当预测业务，感觉预测不准就干脆不预测。

标签：架构设计,架构,预测,可用,复杂度,任务分配,笔记,提炼
来源： https://www.cnblogs.com/wenpeng/p/10661363.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。