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

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


目录
相关文章
|
12天前
|
运维 Kubernetes Docker
利用Docker和Kubernetes构建微服务架构
利用Docker和Kubernetes构建微服务架构
|
18天前
|
运维 持续交付 API
从零构建微服务架构:一次深度技术探索之旅####
【10月更文挑战第28天】 本文记录了作者在从零开始构建微服务架构过程中的深刻技术感悟,通过实战案例详细剖析了微服务设计、开发、部署及运维中的关键要点与挑战。文章首先概述了微服务架构的核心理念及其对企业IT架构转型的重要性,随后深入探讨了服务拆分策略、API网关选型、服务间通信协议选择、容器化部署(Docker+Kubernetes)、以及持续集成/持续部署(CI/CD)流程的设计与优化。最后,分享了在高并发场景下的性能调优经验与故障排查心得,旨在为读者提供一套可借鉴的微服务架构实施路径。 ####
55 3
|
29天前
|
边缘计算 Cloud Native 安全
构建灵活高效的下一代应用架构 随着企业数字化转型的加速,云原生技术正逐渐成为构建现代化应用程序的关键支柱。
随着企业数字化转型加速,云原生技术逐渐成为构建现代化应用的关键。本文探讨了云原生的核心概念(如容器化、微服务、DevOps)、主要应用场景(如金融、电商、IoT)及未来发展趋势(如无服务器计算、边缘计算、多云架构),并分析了面临的挑战,如架构复杂性和安全问题。云原生技术为企业提供了更灵活、高效的应用架构,助力数字化转型。
63 4
|
1月前
|
监控 持续交付 API
深入理解微服务架构:构建高效、可扩展的系统
【10月更文挑战第14天】深入理解微服务架构:构建高效、可扩展的系统
83 0
|
26天前
|
Kubernetes 负载均衡 Docker
构建高效后端服务:微服务架构的探索与实践
【10月更文挑战第20天】 在数字化时代,后端服务的构建对于任何在线业务的成功至关重要。本文将深入探讨微服务架构的概念、优势以及如何在实际项目中有效实施。我们将从微服务的基本理念出发,逐步解析其在提高系统可维护性、扩展性和敏捷性方面的作用。通过实际案例分析,揭示微服务架构在不同场景下的应用策略和最佳实践。无论你是后端开发新手还是经验丰富的工程师,本文都将为你提供宝贵的见解和实用的指导。
|
7天前
|
传感器 算法 物联网
智能停车解决方案之停车场室内导航系统(二):核心技术与系统架构构建
随着城市化进程的加速,停车难问题日益凸显。本文深入剖析智能停车系统的关键技术,包括停车场电子地图编辑绘制、物联网与传感器技术、大数据与云计算的应用、定位技术及车辆导航路径规划,为读者提供全面的技术解决方案。系统架构分为应用层、业务层、数据层和运行环境,涵盖停车场室内导航、车位占用检测、动态更新、精准导航和路径规划等方面。
41 4
|
6天前
|
Kubernetes API Docker
构建高效后端服务:微服务架构的深度实践与优化####
本文深入探讨了微服务架构在现代后端开发中的应用,通过剖析其核心概念、设计原则及实施策略,结合具体案例分析,展示了如何有效提升系统的可扩展性、可靠性和维护性。文章还详细阐述了微服务拆分的方法论、服务间通信的最佳实践、以及容器化与编排工具(如Docker和Kubernetes)的应用技巧,为读者提供了一份全面的微服务架构落地指南。 ####
|
28天前
|
运维 供应链 安全
SD-WAN分布式组网:构建高效、灵活的企业网络架构
本文介绍了SD-WAN(软件定义广域网)在企业分布式组网中的应用,强调其智能化流量管理、简化的网络部署、弹性扩展能力和增强的安全性等核心优势,以及在跨国企业、多云环境、零售连锁和制造业中的典型应用场景。通过合理设计网络架构、选择合适的网络连接类型、优化应用流量优先级和定期评估网络性能等最佳实践,SD-WAN助力企业实现高效、稳定的业务连接,加速数字化转型。
SD-WAN分布式组网:构建高效、灵活的企业网络架构
|
17天前
|
监控 前端开发 JavaScript
探索微前端架构:构建可扩展的现代Web应用
【10月更文挑战第29天】本文探讨了微前端架构的核心概念、优势及实施策略,通过将大型前端应用拆分为多个独立的微应用,提高开发效率、增强可维护性,并支持灵活的技术选型。实际案例包括Spotify和Zalando的成功应用。
|
25天前
|
监控 API 持续交付
构建高效后端服务:微服务架构的深度探索
【10月更文挑战第20天】 在数字化时代,后端服务的构建对于支撑复杂的业务逻辑和海量数据处理至关重要。本文深入探讨了微服务架构的核心理念、实施策略以及面临的挑战,旨在为开发者提供一套构建高效、可扩展后端服务的方法论。通过案例分析,揭示微服务如何帮助企业应对快速变化的业务需求,同时保持系统的稳定性和灵活性。
46 9
下一篇
无影云桌面