2016,我们一起追过的架构。中生代邀您一起构建2017!

简介: 下面是中生代小伙伴石头的2016年终总结,欢迎阅览,并祝您2017万事如意、阖家幸福!
01 属性派

任何系统必有其自身的架构属性。

An architecture—a system’s attributes—and what an architect produces—a setof documents—definitely are not the same thing.

An architectural description (AD) is a set of artifacts that documents anarchitecture in a way its stakeholders can understand and demonstrates that thearchitecture has met their concerns.

石头记:选录这个观点并把它放在本文第一个,是想摧毁架构师的个人主义和英雄主义,以及提醒架构的ownership在团队。特别是在大型组织中,软件架构有时是不受控制的。

02 组成派

软件架构是软件组件及其属性,组件之间关系组成的系统结构。

The software architecture of a program or computing system is the structureor structures of the system, which comprise software elements, the externallyvisible properties of those elements, and the relationships among them.

An architectural element (or just element) is a fundamental piece fromwhich a system can be considered to be constructed.

石头记:这是教科书,也是最基础的思维方式。个人认为组成派更多是从空间维度考虑架构。

03 决策派

软件架构是软件一些重要方面决策的集合。这种说法的典型代表是RUP中对于软件架构的定义。

软件架构包含了关于以下问题的重要决策:
1.
软件系统的组织;
2.
选择组成系统的结构元素和它们之间的接口,以及当这些元素相互协作时所体现的行为;
3.
如何组合这些元素,使它们逐渐组成更大的子系统;
4.
用于指导这个系统组织的架构风格:这些元素以及他们的接口、协作和组合。  
5.
软件架构并不仅仅注重软件本身的结构和行为,还注重其它特性:功能性、性能、可扩展性、可重用性、可理解性以及美学等等。

石头记:依然是教课书般定义,更有设计的感觉。

04桥梁派

Software Architecture in Context is the crucial bridge between requirements and design.

9639e1d360a66510b003cd44f4a1cff788d077c0

The interplay is core to the architectural process.

6a7150a10931549bd655361be913cc094ea59d86


石头记:架构是需求和设计之间的桥梁,并且特别强调和需求方,设计方的互动。这是瀑布研发的思维。

05平衡派

架构是各个方面因素平衡的结果。

cf1ca1cffd58f4ed207a06b58143782666be5bdf

石头记:特别务实的定义方式。花名叫做:"tradeoff"

06康威定律

康威定律:组织结构决定软件架构。

Conway’s law: Organizations which design systems[...] are constrained toproduce designs which are copies of the communication structures of theseorganizations.

设计系统的组织,最终产生的设计等同于组织之内、之间的沟通结构。

石头记:意识到康威定律,是架构师成熟的标志。在微服务架构流行的今天,康威定律被一再的提及。微服务的本质是技术倒逼组织结构变革。你建构了你所知,你所知又影响了建构的方式。”——这或许就是架构和架构师的关系吧。

07建筑派

公元前1世纪,古罗马御用工程师、建筑师MarcusVitruvius Pollio在其《建筑十书》中最早提出了建筑的三要素坚固、实用、美观。英文的表述为Firmitas,Utilitas, Venustas,通俗的说也就是Solid, Useful, Beautiful,用计算机的术语表述就是:

Firmness: Achieve a satisfactory level of freedom from damaging failure.
Commodity: Utility to accomplish the tasks it is purported to be for.
Delight: Pleasure in use.

石头记:时至今日,这三个要素仍然是优秀软件架构的重要组成部分。

08The “4+1” View Model

逻辑视图主要强调面向对象设计;进程视图主要强调并发和同步;物理视图主要强调软件和硬件的映射;部署视图则强调软件在部署环境中的静态组织。场景则强调主需求或者用例。

95795124e3eea4707c8a3752234669b3e69d249a

石头记:经典的“4+1”架构视图,有很多衍生版本。架构师入门必备,是指导软件架构设计,开发实现的重要思想。

09使用视图与视点与利益相关者合作

利益相关者是对架构感兴趣的任何人和组织。关切是利益相关者对架构的任何期许,需求,或目标。

b186010360b567c189f2ff419328c00b00c2a255

视图是架构对利益相关者关切的结构化呈现。视点是构建视角的模式,模板。

1042b065291cf2555f0c757aacc9ff51d65a736a

使用视图和视点的第一个好处是关注点分离。单一视角和很难描述一个复杂系统的架构的。其次是便于和利益相关者沟通。同时便于对系统复杂性进行管理和增加开发者的关注度。其缺点是分片视图,错误视角的选择和视角之间的不一致性。

89e7ffc3dc9d9d07a599b28ec23ba50a4685f22a

架构透视是保证系统属性的一系列活动,策略,指导。

c04df30ac43aa58aa09494c24c508f58ab8bb691

石头记:这是基础而且经典的架构方法。合格架构师拿证的license。掌握此法,可以闯荡架构江湖,还特别适合在大型组织混迹,玩技术。推荐经典书籍:《软件架构设计》,《软件架构师12项修炼》,《软件系统架构:使用视点和视角与利益相关者合作》。

10以终为始

石头记:作者右军是从架构到团队管理,回头再看架构。初级的架构师往往关注在边界和职责,只扫自家门前雪,避免背锅,并以此为荣。作者一针见血,站在用户需求角度考虑架构——以终为始的架构观——阐述了一个良心架构的思考和担当:不为未来挖坑。

作者首创的PMC框架(P>platform\M>merchant\C>customer)值得所有互联网行业的专家借鉴。
从作者的行文中,我对架构的体察总结是:
1.
架构的空间属性:视图,视角,层次
2.
架构的时间属性:动态,演进
3.
架构的组成属性:功能,质量(非功能)

全文以黄金圈理论组织结构,是谓本章架构。

本文有真意,欲辨已忘言。请阅读原文体会妙处。右军以终为始架构观从学习到架构[上篇] 

11环架构

系统架构层面的闭环主要体现在系统监控方面,系统监控主要分为三个层次:
1.
系统层监控,监控底层硬件如CPU、网络和存储等的性能状况;
2.
应用层监控,监控应用性能如页面/服务调用计数,调用延迟,错误计数等;
3.
业务层监控,监控重要的业务指标如PV/UV,用户登录数和订单量等。

baab6a09c8a1fe541da48a354c1a5f27ec87ec08

上图是一个假想的电商网站的分层架构图,
1.
系统层监控,监控底层硬件如CPU、网络和存储等的性能状况;
2.
应用层监控,监控应用性能如页面/服务调用计数,调用延迟,错误计数等
3.
业务层监控,监控重要的业务指标如PV/UV,用户登录数和订单量等。

石头记:作者杨波的文章是我今年认知升级最大信息来源。闭环思维也适用于人,组织,流程。杨波老师原文:拍拍贷基础框架研发实战:构建闭环反馈架构

12演进架构

网站在不同的阶段遇到的问题不一样,而解决这些问题使用的技术也不一样,流量小的时候,主要目的是提高开发效率,在早期要引入ORMDAO这些技术。随着流量变大,使用动静分离、读写分离、主从同步、垂直拆分、CDNMVC等方式不断地提升网站稳定性。面对更大的流量时,通过垂直拆分、服务化、反向代理、开发框架(站点/服务)等等,不断提升高可用。在面对上亿级的更大流量时,通过中心化、柔性服务、消息总线、自动化(回归,测试,运维,监控)来迎接新的挑战。未来的就是继续实现移动化,大数据实时计算,平台化……系统架构会一直迭代衍变,就像最初的从零到现在。

石头记:演化思想是敏捷架构的核心。对很多创业公司,需要仔细读读58同城的技术委员会执行主席沈剑的这篇文章(http://www.csdn.net/article/2015-10-24/2826028)。以及张逸老师的一次设计演进之旅,还有在新美大“创业”:KTV预定业务演进之路途牛订单的服务化演进等。

13全栈架构

全栈,不是全能,和所选择的技术栈甚至业务栈相关。,老曹这么描述全栈的定义。我说过全栈架构师可能是自己的杜撰,但是,全栈思维优先还是被大多数朋友认可的,实际上是一种大局观,一个功能既可以前端又可以后端实现,利弊和方案的选择是需要有全栈架构师的,至少要有全栈的思维。全栈的思维,简单地可以理解成系统的思维方式。

如果问题分为:已知的已知,已知的未知,未知的未知的话,全栈架构师这一角色,就是从未知的未知变成已知的未知。

石头记:全栈思维和全栈能力,架构师的硬技能。老曹的原文 -听说过全栈工程师,那全栈架构师又是什么鬼?

14软件是用户参与的协同创造

张林老师从一个问题出发:你重新开发一个微信,和微信的功能一模一样,还是微信吗?没有用户的微信它还是微信吗?由此推导出软件是代码+算法+数据结构+用户。

由此,软件开发就是开发者和用户群体创造的信息再造过程。而架构是对大量无结构的信息进行重构整合梳理,得到有结构的信息的过程。

石头记:是技术承载双11的狂欢?还是双11的狂欢塑造了技术架构?张林老师原文:务实的研发领导力

15架构扩展立方体

13ffacbb102afefe2ad26c1a8781b8b79fe55b4b

石头记:推荐经典书籍《架构即未来》

16
架构扩展原则

AKF采用的最普遍的架构原则:
1
N+1设计
2
、回滚设计
3
、禁用设计
4
、监控设计
5
、设计多活数据中心
6
、使用成熟的技术
7
、异步设计
8
、无状态系统
9
、水平扩展非垂直升级
10
、设计至少要有两个步骤的前瞻性
11
、非核心则购买
12
、使用商品化硬件
13
、小构建、小发布、快试错
14
、隔离故障
15
、自动化

石头记:推荐经典书籍《架构即未来》。

17 OKR架构观

石头记:这个是石头的杜撰。石头一直认为,优秀的架构师应该首先负责关键技术的突破,解决技术可行性问题,拿出从01的那些关键结果。
18
架构六步思考法

美团点评外卖配送和到店餐饮总架构师夏华夏总结架构师三大能力和六步思考法。

架构师三大能力:
1.
站的高——考虑整体:站在更高的层次综合看问题
2.
望的远——考虑未来:良好的前瞻和规划
3.
扎的深——考虑细节:洞察底层落地的细节

架构六步思考法:

1cdb4f51ea6fcc85d48e3ac6647ff8fffb89dd77

石头记:架构过程的闭环,很多团队都没有完成这个闭环吧?

19开发运营三板斧

The Three Ways: The Principles Underpinning DevOps.内容来自:

http://itrevolution.com/the-three-ways-principles-underpinning-devops/

3fa182afb0a401acc3aa503303bca093a40e2832

4e772a8b2d246b9ca7eda01d29da31b74fbb3320

65f81f36382206d595a152f5d86d274b5b09695a

石头记:强调从开发到运维的价值流,打破组织壁垒。并在这个价值流上增强反馈闭环,提高交付效率。团队文化上支持不断试错。思考一下三板斧是否反映出你的组织存在的问题?

 20领域驱动架构设计

b1ce507c5369f7a854dfbcae11c3045c4adb9f39

石头记:推荐经典书籍:《领域驱动设计:软件核心复杂性应对之道》。


目录
相关文章
|
1天前
|
运维 Cloud Native 持续交付
构建未来:云原生架构在企业数字化转型中的关键作用
【5月更文挑战第7天】 随着企业加速其数字化转型的步伐,云原生架构已成为推动创新及实现敏捷性的重要驱动力。本文将探讨云原生技术的基本原理,分析其在现代企业中的应用,并讨论如何借助云原生方法提升业务的弹性、可扩展性和效率。通过案例研究和最佳实践的分享,我们揭示了云原生解决方案如何助力企业在竞争激烈的市场中保持领先。
|
1天前
|
设计模式 Kubernetes 数据库
构建高效可靠的微服务架构:后端开发的新范式
【5月更文挑战第7天】在现代软件开发的浪潮中,微服务架构已经成为一种流行的设计模式。它通过将应用程序分解为一组小的、独立的服务来提高系统的可维护性和扩展性。本文深入探讨了微服务架构的核心概念、优势以及如何利用最新的后端技术构建一个高效且可靠的微服务体系。我们将讨论关键的设计原则,包括服务的独立性、通信机制、数据一致性和容错性,并展示如何在云环境中部署和管理这些服务。
|
1天前
|
Kubernetes Cloud Native 持续交付
构建未来:云原生架构在企业数字化转型中的关键角色
【5月更文挑战第7天】 随着企业加速数字化转型,云原生架构已成为推动创新和敏捷性的重要驱动力。本文将深入探讨云原生技术的基本原理,以及如何利用这些技术实现业务灵活性和响应速度的显著提升。通过分析微服务、容器化、持续集成/持续部署(CI/CD)等关键组件,我们将揭示云原生架构如何帮助企业应对快速变化的市场需求,同时确保系统的稳定性和可扩展性。
|
1天前
|
Cloud Native 安全 持续交付
构建未来:云原生架构在企业数字化转型中的关键作用
【5月更文挑战第6天】 随着企业加速其数字化进程,云原生架构已不仅仅是一种趋势,而成为推动业务敏捷性、可扩展性和创新的基石。本文深入探讨了云原生技术如何通过提供灵活的开发环境、微服务架构和持续交付机制,促进企业快速响应市场变化,并实现资源的最优化配置。通过分析多个行业案例,我们阐述了云原生架构实施的最佳实践,以及它如何帮助企业保持竞争优势,并为未来的技术演进打下坚实基础。
|
1天前
|
缓存 监控 数据库
构建高性能微服务架构:后端开发的终极指南
【5月更文挑战第6天】 在现代软件开发的浪潮中,微服务架构以其灵活性、可扩展性和容错性引领着技术潮流。本文深入探索了构建高性能微服务架构的关键要素,从服务划分原则到通信机制,再到持续集成和部署策略。我们将透过实战案例,揭示如何优化数据库设计、缓存策略及服务监控,以确保系统的稳定性和高效运行。文中不仅分享了最佳实践,还讨论了常见的陷阱与解决之道,为后端开发者提供了一条清晰、可行的技术路径。
|
2天前
|
消息中间件 数据管理 持续交付
构建高效微服务架构的最佳实践
【5月更文挑战第6天】在动态和快速演变的现代软件开发领域,微服务架构已经成为促进敏捷开发和部署的关键模式。本文将深入探讨构建和维护高效微服务架构的策略,包括服务划分准则、通信机制、数据管理及持续集成与持续交付(CI/CD)的实施。通过分析不同业务场景下的应用案例,本文旨在为开发者提供一套行之有效的指导原则和实践方法,以支持他们构建可扩展、灵活且高效的微服务系统。
18 2
|
2天前
|
Kubernetes Cloud Native 持续交付
构建高效云原生应用:Kubernetes与微服务架构的融合
【5月更文挑战第6天】 在数字化转型的浪潮中,企业正迅速采纳云原生技术以实现敏捷性、可扩展性和弹性。本文深入探讨了如何利用Kubernetes这一领先的容器编排平台,结合微服务架构,构建和维护高效、可伸缩的云原生应用。通过分析现代软件设计原则和最佳实践,我们提出了一个综合指南,旨在帮助开发者和系统架构师优化云资源配置,提高部署流程的自动化水平,并确保系统的高可用性。
22 1
|
2天前
|
API 持续交付 开发者
构建高效微服务架构:策略与实践
【5月更文挑战第6天】随着现代软件系统的复杂性增加,微服务架构逐渐成为企业开发的首选模式。本文深入分析了构建高效微服务架构的关键策略,并提供了一套实践指南,帮助开发者在保证系统可伸缩性、灵活性和稳定性的前提下,优化后端服务的性能和可维护性。通过具体案例分析,本文将展示如何利用容器化、服务网格、API网关等技术手段,实现微服务的高可用和敏捷部署。
|
2天前
|
监控 负载均衡 持续交付
构建高效微服务架构:后端开发的新趋势
【5月更文挑战第5天】在数字化转型的浪潮中,微服务架构以其灵活性、可扩展性和容错性成为企业追求的技术典范。本文深入探讨了微服务的核心组件、设计原则和实施策略,旨在为后端开发者提供构建和维护高效微服务系统的实用指南。通过分析微服务的最佳实践和常见陷阱,我们揭示了如何优化系统性能、保证服务的高可用性以及如何处理分布式系统中的复杂性。
|
3天前
|
缓存 NoSQL Java
构建高性能微服务架构:Java后端的实践之路
【5月更文挑战第5天】在当今快速迭代和高并发需求的软件开发领域,微服务架构因其灵活性、可扩展性而受到青睐。本文将深入探讨如何在Java后端环境中构建一个高性能的微服务系统,涵盖关键的设计原则、常用的框架选择以及性能优化技巧。我们将重点讨论如何通过合理的服务划分、高效的数据存储策略、智能的缓存机制以及有效的负载均衡技术来提升整体系统的响应速度和处理能力。