关于系统设计原则回顾

2019-12-22 11:54 来源:未知

     前段时间有人问作者系统规划的标准,事实上无论前不久相继技巧栈怎么演化,这一个本质的原则与方式不会变, 让我们回看一下 那么些标准:

•分散关心 Separation of concerns. Divide your application into distinct features with as little overlap in functionality as possible. The important factor is minimization of interaction points to achieve high cohesion and low coupling. However, separating functionality at the wrong boundaries can result in high coupling and complexity between features even though the contained functionality within a feature does not significantly overlap. 区别世界的成效,应该由不一样的代码和微小重迭的模块组成。

•单风华正茂职分,作用高内聚 Single Responsibility principle. Each component or module should be responsible for only a specific feature or functionality, or aggregation of cohesive functionality.

•贰个模块无需领会另三个模块的内部细节 Principle of Least Knowledge (also known as the Law of 德姆eter or LoD卡塔尔. A component or object should not know about internal details of other components or objects.

•Don’t repeat yourself (DRY). You should only need to specify intent in one place. For example, in terms of application design, specific functionality should be implemented in only one component; the functionality should not be duplicated in any other component.

•不要过分设计过多模块 Minimize upfront design. Only design what is necessary. In some cases, you may require upfront comprehensive design and testing if the cost of development or a failure in the design is very high. In other cases, especially for agile development, you can avoid big design upfront (BDUF). If your application requirements are unclear, or if there is a possibility of the design evolving over time, avoid making a large design effort prematurely. This principle is sometimes known as YAGNI ("You ain’t gonna need it").

图片 1

软件设计 中 SOLID原则

Simplicity (KISS)

     The most important principle is keeping things simple. 轻巧是软件设计的目的,轻易的代码占用时间少,漏洞少,何况易于修改。Simplicity should be your northern star, your compass, and your long-term commitment. Keeping software simple is difficult because it is inherently relative. There is no standardized measurement of simplicity, so when you judge what is simpler, you need to first ask yourself for whom and when. For example, is it simpler for you or for your clients? Is it simpler for you to do now or maintain in the future?

低耦合原则(Minimize Coupling卡塔尔(قطر‎

       代码的任何二个有的应该收缩对别的区域代码的依据关系。尽量不要接受分享参数。低耦合往往是关怀备至布局连串和完美设计的注明

Designing for scale      Designing for scale is a difficult art, and each technique described in this section comes with some costs. As an engineer, you need to make careful tradeoffs between endless scalability and the practicality of each solution. To make sure you do not over engineer by preparing for scale that you will never need, you should first carefully estimate the most realistic scalability needs of your system and design accordingly.
Design for Self-Healing      The final design principle in this chapter is designing software for high availability and self-healing. A system is considered to be available as long as it performs its functions as expected from the client's perspective. It does not matter if the system is experiencing internal partial failure as long as it does not affect the behavior that clients depend on. In other words, you want to make your system appear as if all of its components were functioning perfectly even when things break and during maintenance times.
Designing For Failure      Each application component must be deployed across redundant cloud components, ideally with minimal or no common points of failure
      Each application component must make no assumptions about the underlying infrastructure—it must be able to adapt to changes in the infrastructure without downtime
      Each application component should be partition tolerant—in other words, it should be able to survive network latency (or loss of communication) among the nodes that support that component
      Automation tools must be in place to orchestrate application responses to failures or other changes in the infrastructure

部分企划的进行

Keep design patterns consistent within each layer. Within a logical layer, where possible, the design of components should be consistent for a particular operation. For example, if you choose to use the Table Data Gateway pattern to create an object that acts as a gateway to tables or views in a database, you should not include another pattern such as Repository, which uses a different paradigm for accessing data and initializing business entities. However, you may need to use different patterns for tasks in a layer that have a large variation in requirements, such as an application that contains business transaction and reporting functionality.
Do not duplicate functionality within an application. There should be only one component providing a specific functionality—this functionality should not be duplicated in any other component. This makes your components cohesive and makes it easier to optimize the components if a specific feature or functionality changes. Duplication of functionality within an application can make it difficult to implement changes, decrease clarity, and introduce potential inconsistencies.
Prefer composition to inheritance. Wherever possible, use composition over inheritance when reusing functionality because inheritance increases the dependency between parent and child classes, thereby limiting the reuse of child classes. This also reduces the inheritance hierarchies, which can become very difficult to deal with.
Establish a coding style and naming convention for development. Check to see if the organization has established coding style and naming standards. If not, you should establish common standards. This provides a consistent model that makes it easier for team members to review code they did not write, which leads to better maintainability.
Maintain system quality using automated QA techniques during development. Use unit testing and other automated Quality Analysis techniques, such as dependency analysis and static code analysis, during development. Define clear behavioral and performance metrics for components and sub-systems, and use automated QA tools during the build process to ensure that local design or implementation decisions do not adversely affect the overall system quality.
Consider the operation of your application. Determine what metrics and operational data are required by the IT infrastructure to ensure the efficient deployment and operation of your application. Designing your application’s components and sub-systems with a clear understanding of their individual operational requirements will significantly ease overall deployment and operation. Use automated QA tools during development to ensure that the correct operational data is provided by your application’s components and sub-systems.

在网络系统下发生的生龙活虎部分规格

1.幸免单点故障:任何事物都要有四个。那扩张了资本和复杂度,但却能在可用性和负载质量上收入。并且,那促进设计者接纳风姿浪漫种布满式优先的沉凝。可(异域)计划和就地路由连接,破除单点故障;可布满,可调治的尺度

2.横向扩充,实际不是纵向增添:进级服务器(纵向)的工本是指数增进的,而充实另生机勃勃台湾商人用服务器(横向)的资本是线性拉长的。
3.尽量精减应用程序大旨所供给产生的做事。

4.API优先:将应用程序视为叁个提供API的劳务,并且,不假定服务的顾客端类型(手提式无线电话机使用、Web站点、桌面应用程序)。

5.提供尽大概新的数据:客户或然无需及时看见最新的数目,最后生机勃勃致性可以拉动更加高的可用性。
6.企划时要考虑有限协助和自动化:不要低估应用程序维护所供给的时间和专业量。软件首次公开采布是一个值得赞赏的里程碑,但也标记着真正的办事要初叶了。
7.为故障做好准备:将故障对终极客户的熏陶最小化。
8.多少反映和监督检查平台;
顾客作为数据,系统天性监察和控制数据,系统十三分和作业有关数据等的陈说
9.数量分级存款和储蓄原则:单内部存款和储蓄器cache存款和储蓄,内部存款和储蓄器cache+异步更新,内部存款和储蓄器cache+同步校勘;
从多少个纬度深入分析客商作为模型,决定有关数据的仓库储存计策:1卡塔尔(英语:State of Qatar),能经得住顾客数量的不见吗?2卡塔尔,能忍受多少的非及时性吗? 3卡塔尔(قطر‎,数据的读写比例分布如何?
10.意况分离原则;
能静态化尽量静态化,在代码和进程计划上,在DNS层上抓牢气象分离的系统规划计划
11.轻重分离原则;
有限扶持衔接和事务管理的告辞,接入尽量轻量化,使得系统有着很好的吞吐量,处理尽量异步化,使得能够平滑扩充
12. 毁灭服务注重原则:同后生可畏IDC的其余服务对系统的熏陶,第三方调用系统接口的隔绝和过载珍贵,信赖第三方服务的监督检查和平安全保捍卫保护标准等。
13.柔性可用原则;
处理好分外情形下的灰度体验,区分好根本管理渠道和非关键路线,而系统规划要尽量把主要路线调换来非关键路线
14.异步化,能异步的尽量异步原则;
透过内部存款和储蓄器管道,操作流水等手艺拓宽拼接各类管理模块
15.灰度规格;
灰度发表政策是依据客商号码段,客户ip段,照旧顾客vip品级,客户所在城市等张开灰度晋级,保证系统的平整迭代
16.百般的急速响应和风华正茂键切换原则;
IDC断电?系统切换来健康的本钱是不怎么?时间啊?供给几人操作?牛的系统能够一人在保管后台按叁个按键就足以切换,再按一下就可以切换回来
17.有损服务标准;
用低本钱提供海量的劳务标准
18.充裕利用DNS层做好系统的可分布设计
19.区分系统作为和客户作为并分别张开设计,以致在关键时刻可以扩充更动。
20.努力完毕无状态:状态新闻要封存在尽大概少的地点,何况要保留在专门设计的构件中。百折不挠app_server设计的无状态统筹标准,调换客商作为为系统作为,使得app_server具备无状态的特征
21.多级cache设计以致各类cache的路由设计
22.“概略系小做”原则  
23.强专门的学业模型到结尾后生可畏致性事务模型的转换原则
24.尽恐怕拆分
25.劳务布局“去大旨化”
26.数据化运行
27.尽或者使用成熟组件
28.尽可能自动化

周围web系统规划的有个别中坚标准:

可用性: 二个网址的健康运营时刻对于众多铺面包车型大巴名望与运作都以首要的。对于部分更大的在线零售站点,几分钟的不可用都会形成数千或数百万英镑的营收损失,因而系统规划得能够不断服务,何况能飞快从故障中回复是工夫和业务的最基本须要。遍布式系统中的高可用性必要精心思忖关键零器件的冗余,从局地系统故障中不慢复原,以至难题发生时高雅降级。
性能: 对于好多站点来讲,网址的本性已形成多个第意气风发的考虑要素。网址的进程影响着使用和客户满足度,以致查找引擎排行,与营业收入和是或不是能留下客户直接相关。因而,创立三个针对性急迅响应与低顺延实行优化的系统丰盛关键。
可靠性: 系统必得是牢靠的,那样平等数量恳求才会一贯再次来到相近的数码。数据转变或更新之后,相同的倡议则应该回到新的多少。顾客应该通晓一点:假如东西写入了系统,或许拿到存储,那么它会持久化并且料定保持不改变以便现在开展寻找。
可扩充性: 对于别的大型遍布式系统来说,大小(size卡塔尔(英语:State of Qatar)只是索要思虑的层面(scale卡塔尔(英语:State of Qatar)难点的三个方面。相通举足轻重的是着力去加强管理越来越大负荷的技能,那平日被称呼系统的可扩展性。可增加性以种类的数不胜数不相同参数为参照:能够管理多少额外流量?扩大存款和储蓄体积有多轻松?能够处理多少越来越多的事务?
可管理性: 系统规划得轻巧运营是另贰个重大的思量要素。系统的可管理性等价于运转(维护和立异)的可扩充性。对于可管理性须要思谋的是:难题时有发生时便于诊断与通晓,便于更新或改革,系统运转起来何等轻易(举个例子:常规运行是或不是不会掀起失利或特别?)
成本: 花费是二个重要成分。很显眼那包涵硬件和软件花销,但也要考虑系统架议和保障那黄金时代派。系统创设所花费的开垦者时间,系统运维所须要的运行专业量,以致陶铸工作都应当考虑进来。费用是颇有系统的总资金。

剩下来 就足以围绕 ISO 9126成色模型:软件品质模型的6大特色和三十多个子天性来进展系统规划与剖析,衡量, 他们是:

一、功能性:
1、相符性:提供了相应的效应
2、正确性:正确(顾客须要的)
3、互操作性:产物与制品中间相互数据的力量
4、保密安全性:允许通过授权的客户和类别能够不奇怪的会见相应的多少和音讯,禁绝未授权的顾客访谈.......
5、功用性的依从性:国际/国家/行业/集团 典型规范生龙活虎致性

二、可相信性:成品在显著的原则下,在鲜明的岁月内形成规定职能的技艺
1、成熟性:制止内部错误形成软件失效的技术
2、容错性:软件现身故障,自己管理能力
3、易恢复生机性:失效情形下的复原技艺
4、可信性的依从性

三、易用性:在指定使用条件下,成品被精通、 学习、使用和引发顾客的力量
1、易精晓性:
2、易学性:
3、易操作性:
4、吸引性:
5、易用性的依从性:

四、作用性:在规定台规范下,相对于所用财富的数据,软件出品可提供适当品质的本事
1、时间脾气:平均事务响适当时候间,吞吐率,TPS(每秒事务数)
2、能源利用性:CPU 内部存款和储蓄器 磁盘 IO 互连网带宽 队列 分享内部存储器
3、作用依从性:

五、软件维护性:"四规", 在明确条件下,规定的年月内,使用规定的工具或格局修复规定职能的力量
1、易剖判性:解析定位难点的难易程度
2、易纠正性:软件出品使钦命的校正能够被完结的技艺
3、稳固性:防止意外改革引致程序失效
4、易 测量试验性:使已更正软件能被承认的力量
5、维护性的依从性

六、软件可移植性:从生龙活虎种情状迁移到另少年老成种意况的力量
1、适应性:适应差异平台
2、易安装性:被设置的技艺
3、共存性:
4、易替换性
5、可移植性的依从性:

悉心回顾以后每一项的系统平台,框架,组件,工程措施,都最少含有有地点的筹算思想与标准。可能还应该有疏漏的,后续补充。


后天先到那时,希望对你在系统构造设计与评估,团队处理, 项目管理, 付加物管理有参照效能 , 您也许感兴趣的作品:
网络电子商务购物车构造演变案例
网络业务场景下音讯队列布局
音讯系统布局划杜撰计演进
网络电子商务寻找布局衍生和变化之大器晚成
同盟社消息化与软件工程的迷思
杂货店项目化管理介绍
软件项目成功之要素
人际交往风格介绍生龙活虎
精益IT组织与共享式领导
学习型协会与公司
商铺立异文化与品级理念
团队目的与个人目的
初创公司人才招聘与管理
美丽集团蒙受与公司文化
商场文化、团队文化与学识分享
高作用的团体建设
类型管理关系陈设
创设高效的研究开发与自动化运行
某大型电子商务云平台实施
互连网数据库结构划虚构计思路
IT底子结构规划方案少年老成(互连网体系规划卡塔尔(قطر‎
餐饮行当技术方案之客商分析流程
餐饮行当解决方案之买卖战略制订与试行流程
餐饮行当技术方案之业务设计流程
供应链须求应用商量CheckList
公司应用之性质实时衡量系统演变

如有想询问更加多软件设计与布局, 系统IT,集团新闻化, 团队保管 资源音讯,请关切笔者的Wechat订阅号:

图片 2

作者:Petter Liu
出处:
本文版权归笔者和乐乎共有,款待转发,但未经小编同意必需保留此段注明,且在篇章页面显著地点给出原作连接,不然保留追查法律权利的职务。
该随笔也还要揭露在自个儿的单独博客中-Petter Liu Blog。

TAG标签:
版权声明:本文由澳门国际银河备用网址发布于澳门国际银河备用网址,转载请注明出处:关于系统设计原则回顾