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

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


目录
相关文章
|
24天前
|
监控 网络协议 Nacos
Nacos:构建微服务架构的基石
Nacos:构建微服务架构的基石
71 2
|
25天前
|
前端开发 JavaScript 测试技术
Kotlin教程笔记 - 适合构建中大型项目的架构模式全面对比
Kotlin教程笔记 - 适合构建中大型项目的架构模式全面对比
26 3
|
5天前
|
监控 安全 API
使用PaliGemma2构建多模态目标检测系统:从架构设计到性能优化的技术实践指南
本文详细介绍了PaliGemma2模型的微调流程及其在目标检测任务中的应用。PaliGemma2通过整合SigLIP-So400m视觉编码器与Gemma 2系列语言模型,实现了多模态数据的高效处理。文章涵盖了开发环境构建、数据集预处理、模型初始化与配置、数据加载系统实现、模型微调、推理与评估系统以及性能分析与优化策略等内容。特别强调了计算资源优化、训练过程监控和自动化优化流程的重要性,为机器学习工程师和研究人员提供了系统化的技术方案。
111 77
使用PaliGemma2构建多模态目标检测系统:从架构设计到性能优化的技术实践指南
|
27天前
|
运维 负载均衡 Shell
控制员工上网软件:高可用架构的构建方法
本文介绍了构建控制员工上网软件的高可用架构的方法,包括负载均衡、数据备份与恢复、故障检测与自动切换等关键机制,以确保企业网络管理系统的稳定运行。通过具体代码示例,展示了如何实现这些机制。
119 63
|
8天前
|
缓存 Kubernetes 容灾
如何基于服务网格构建高可用架构
分享如何利用服务网格构建更强更全面的高可用架构
|
18天前
|
弹性计算 持续交付 API
构建高效后端服务:微服务架构的深度解析与实践
在当今快速发展的软件行业中,构建高效、可扩展且易于维护的后端服务是每个技术团队的追求。本文将深入探讨微服务架构的核心概念、设计原则及其在实际项目中的应用,通过具体案例分析,展示如何利用微服务架构解决传统单体应用面临的挑战,提升系统的灵活性和响应速度。我们将从微服务的拆分策略、通信机制、服务发现、配置管理、以及持续集成/持续部署(CI/CD)等方面进行全面剖析,旨在为读者提供一套实用的微服务实施指南。
|
16天前
|
负载均衡 Java 开发者
深入探索Spring Cloud与Spring Boot:构建微服务架构的实践经验
深入探索Spring Cloud与Spring Boot:构建微服务架构的实践经验
59 5
|
14天前
|
监控 安全 持续交付
构建高效微服务架构:策略与实践####
在数字化转型的浪潮中,微服务架构凭借其高度解耦、灵活扩展和易于维护的特点,成为现代企业应用开发的首选。本文深入探讨了构建高效微服务架构的关键策略与实战经验,从服务拆分的艺术到通信机制的选择,再到容器化部署与持续集成/持续部署(CI/CD)的实践,旨在为开发者提供一套全面的微服务设计与实现指南。通过具体案例分析,揭示如何避免常见陷阱,优化系统性能,确保系统的高可用性与可扩展性,助力企业在复杂多变的市场环境中保持竞争力。 ####
33 2
|
14天前
|
弹性计算 Kubernetes API
构建高效后端服务:微服务架构的深度剖析与实践####
本文深入探讨了微服务架构的核心理念、设计原则及实现策略,旨在为开发者提供一套系统化的方法论,助力其构建灵活、可扩展且易于维护的后端服务体系。通过案例分析与实战经验分享,揭示了微服务在提升开发效率、优化资源利用及增强系统稳定性方面的关键作用。文章首先概述了微服务架构的基本概念,随后详细阐述了其在后端开发中的应用优势与面临的挑战,最后结合具体实例,展示了如何从零开始规划并实施一个基于微服务的后端项目。 ####
|
18天前
|
消息中间件 监控 安全
构建高效微服务架构:最佳实践与挑战
在现代软件开发中,微服务架构因其高度的可扩展性、灵活性和敏捷性而受到青睐。本文深入探讨了构建高效微服务架构的关键策略,包括服务的划分、通信机制、数据管理、部署与监控等方面的最佳实践。同时,文章也分析了在实施过程中可能遇到的挑战,如服务间的依赖管理、数据一致性问题、安全考量及性能优化等,并提出了相应的解决方案。通过实际案例分析,本文旨在为开发者提供一套实用的指南,帮助他们在构建微服务系统时能够有效规避风险,提升系统的健壮性和用户体验。