关注并星标腾讯云开发者
每周3 | 谈谈我在腾讯的架构规划阅历
第1期 | 黄规速：在腾讯做架构规划的15大原则与6个避坑思想
在软件行业，关于什么是架构一直有许多的争论，每个人都有自己的了解。不同的书本上、不同的作者，关于架构的定义也不一起，角度不同，定义不同。此君说的架构和彼君了解的架构未必是一回事。
因此我们在谈论架构之前，我们先谈论架构的概念定义，因为概念是人知道这个国际的基础和用来沟通的手法，假定对架构概念了解不一样，那沟通起来天然不顺利。
Linux 有架构，MySQL 有架构，JVM 也有架构，运用 Java 开发、MySQL 存储、跑在 Linux 上的业务系统也有架构，应该关注哪一个？想要清楚以上问题需求收拾几个有联络又相似的概念：系统与子系统、模块与组成、结构与架构。
系统与子系统
系统：泛指由一群有相关的单个组成，根据某种规则运作，能结束单个元件不能独立结束的作业才华的集体。提到系统，我们有必要了解以下几个要害词：
相关：系统是由一群有相关的单个组成的，没有相关的单个堆在一起不能成为一单个系。例如，把一个主张机和一台 PC 放在一起不能称之为一单个系，把主张机、底盘、轮胎、车架组合起来才华成为一台轿车。
规则：系统内的单个需求按照指定的规则运作，而不是单个个单个各自为营。规则规则了系统内单个分工和协作的方法。例如，轿车主张机担任产生动力，然后通过变速器和传动轴，将动力输出到车轮上，从而驱动轿车跋涉。
才华：系统才华与单个才华有实质的差别，系统才华不是单个才华之和，而是产生了新的才华。例如，轿车能够载重跋涉，而主张机、变速器、传动轴、车轮自身都不具有这样的才华。
子系统：也是由一群相关的单个组成的系统，多半是在更大的系统中的一部分。
模块与组件
它们都是系统的组成部分，从不同角度拆分系统而已。模块是逻辑单元，组件是物理单元。
模块就是从逻辑大将系统分解， 即分而治之， 将凌乱问题简略化。模块的粒度可大可小， 可所以系统、几个子系统、某个服务、函数、类、方法、 功用块等等。区别模块的首要目的是职责分别。
组件能够包括运用服务、数据库、网络、物理机，还能够包括 MQ、容器、Nginx 等技术组件。区别组件的首要目的是单元复用。“组件”的英文单词 Component，对应中文的“零件”一词，“零件”更简单了解一些。“零件”是一个物理的概念，并且具有“独立且可替换”的特色。现在越来越被的 UI 规划运用组件化和模块化。
结构与架构
结构一般指的是为了结束某个业界标准或结束特定底子任务的软件组件标准，也指为了结束某个软件组件标准时，供应标准所要求之基础功用的软件产品。
结构是组件结束的标准，例如：MVC、MVP、MVVM 等，是供应基础功用的产品，例如开源结构：Ruby on Rails、Spring、Laravel、Django 等，这是能够拿来直接运用或许在此基础上二次开发。
再例如，SpringMVC 是 MVC 的开发结构，除了满足 MVC 的标准，Spring 供应了许多基础功用来协助我们结束功用，包括注解(@Controller等)、Spring Security、SpringJPA 等许多基础功用。
结构是标准，架构是结构。
结构和架构的差异仍是比较显着的，结构关注的是“标准”，架构关注的是“结构”。结构的英文是 Framework 。例如，SpringMVC 是”Web MVC Framework”。架构的英文是 Architecture。例如，Linux 操作系统的架构。
在 TOGAF9 是这么定义：一单个系底子的构件（子系统，模块，组件），体现在它的各个构件、构件间的互相联络、构件与环境间的联络，以及对系统规划和演进进行处理的原则中。
两种含义：
▶︎ 第一，一单个系的方式化描绘，或教导系统结束的构件级的详细计划。
▶︎ 第二，一组构件的结构、构件间的互相联络，以及对这些构件的规划和随时间演进的进程进行处理的一些原则和教导战略。
架构从字面意思上，是源于古代的修建术语。
把架构拆分红两个字“架”和“构”。“架”就是“加”和“木”的结合，把木头加起来、联接起来就是架。“构”就是结构的意思。所以，“架构”就是把“木”按照必定的结构联接起来。
对应到软件架构，“木”代表构件（要素），“结构”代表架构的产品：木就是系统中的要素，我们将它们称之为架构构件（要素）。架构要素可所以子系统、模块、运用服务、组件。结构，是架构的产品。不同的软件系统会有不同的结构，这些结构是为处理不同场景而规划的。
联接，通过定义架构元素之间的接口和交互联络、集成机制，结束架构元素之间的联接。联接可所以分布式调用、进程间调用、组件之间的交互联络等。总结一下架构的组成 = 要素 + 结构 + 联接，将系统要素按照特定结构进行联接交互。
我在这从头定义架构（见仁见智）：
软件架构指软件系统顶层结构规划。
架构是通过系统性地考虑，权衡利弊之后在现有资源捆绑下的最合理抉择计划，毕竟清楚的系统骨架：包括子系统、模块、组件，以及他们之间协作联络、捆绑标准、教导原则，并由它来教导系统各方面的规划和教导团队中的每个人思想层面上的一起。
触及四方面：
▶︎ 系统性考虑的合理抉择计划：比如技术选型、处理施行计划（包括实行方针计划）、本钱点评、性价比点评等等。
▶︎ 结构：清楚的系统骨架（结构）：清楚系统有哪些构件组成。
▶︎ 联接：系统协作联络：各个组成部分怎样协作来结束业务请求。
▶︎ 标准：捆绑标准和教导原则：确保系统有序，高效、安稳工作，包括标准、原则、流程等内容。
假定没有架构规划，说明你的系统不可凌乱。跟着业务的增加，系统由单体运用渐进演化为分布式和微服务化。
系统全体的凌乱性越来越高，技术团队或许从一个团队变成多个专业化团队。假定没有架构规划，系统定会是一个无序失控的情况，带来的问题：
| 问题 | 原因 |
|---|---|
| 运用服务的鸿沟不清楚 | 到底该怎样拆分没有一个清楚的原则，研发人员为了所谓微服务化而拆分，而不是从当时业务考虑。导致系统无序地情况，开发功率低。我们系统出现过相似的情况：一个简略项目拆分红8个子服务，问他为什么这么拆分，说微服务化是为了应对往后扩展便当。结果这个项目从2017年到现在都没有再批改正，接手人甘愿新开发一个项目也不肯重构。 |
| 运用服务层次不清楚，系统耦合严重 | 导致服务依托出现网状依托结构，牵一主张全身，后续批改和扩展困难。 |
| 系统运用服务盯梢问题 | 因为微服务化后，系统逻辑凌乱，服务出现问题后，你很难快速地定位问题和批改。这是我们踩过不少坑，我们运用 dubbo 服务化，系一起旦出现问题，一堆人手忙脚乱。 |
| 系统服务监控问题 | 因为研发人员底子没有服务监控意识，都是出现问题后再想方法怎样添加服务监控接口。 |
| 技术系统失控问题 | 不同的开发团队运用不同的技术栈或许组件，造成公司内部的技术架构失控。乃至研发人员为寻求时髦新潮技术，拿运用项目来试验新技术。 |
当然，我们还能列举出更多问题。
架构规划的目的是为了处理系统凌乱性带来的问题。其实质就是对系统进行有序化地重构致使符合当时业务的打开，并能够快速扩展。
从上面架构的定义，也知道架构规划的效果触及四方面：系统性考虑的合理抉择计划；清楚的系统骨架；系统协作联络；捆绑标准和教导原则。
无论是何种改变，架构师通过了解业务、全局把控，权衡业务需求和技术结束。挑选适宜技术，处理要害问题并教导研发落地施行，毕竟促进业务打开，前进功率。
在 EA 架构范畴，有两种常见架构方法 RUP 和 TOGAF，这两个结构也是我们常常了解架构分类的两个维度。
从我个人的角度觉得 TOGAF 的分类方法更加广泛运用，因此本次同享我简略打开介绍 TOGAF ，假定你对 RUP 感兴趣，举荐阅览1995年，Philippe Kruchten 在《IEEE Software》上宣布了题为《The 4+1 View Model of Architecture》的论文。
TOGAF9 对架构的分类是这样的：
| 架构类型 | 描绘 |
|---|---|
| 业务架构 | 业务战略、处理、组织和要害业务流程。 |
| 数据架构 | 组织的各类逻辑和物理数据资产以及数据处理资源的结构。 |
| 运用架构 | 描绘被安置的单个运用系统、系统之间的交互，以及它们与组织中心业务流程之间联络的蓝图。 |
| 技术架构 | 关于支撑业务、数据和运用服务的安置来说必需的逻辑软、硬件才华。包括1T基础设施、中心件、网络、通讯、安置处理和一些标准等。 |
因为不同架构方法论，定义的架构分类也不同，RUP4+1架构方法首要是以架构生命周期为视角进行描绘，而 TOGAF9 按架构触及内容维度来描绘。
因此我结合两者细分为业务架构、运用架构、数据架构、技术架构、代码架构、安置架构。
业务架构是战略，运用架构是战术，技术架构是配备。其间运用架构承上启下，一方面接受业务架构的落地，另一方面影响技术选型。了解业务，构成业务架构；根据业务架构作出相应的运用架构，最终技术架构落地施行。
你也能够了解成：业务架构是出产力，运用架构是出产联络，技术架构是出产东西。业务架构决定运用架构，运用架构需求适配业务架构，并跟着业务架构不断进化，一起运用架构依托技术架构毕竟落地。
全体来说，架构演进旅程是这样的：
单体运用->分布式运用服务化->微服务
下面我将做简略介绍。
单体运用
企业一开始业务比较简略，只运用某个简略场景，运用服务支撑数据增批改查和简略的逻辑即可，单体运用能够满足要求。
典型的三级架构：前端（Web/手机端）+中心业务逻辑层+数据库层。这是一种典型的 Java Spring MVC 或许 Python Django 结构的运用。针对单体运用，非功用性需求的做法：
▶︎ 功用需求：运用缓存改进功用；
▶︎ 并发需求：运用集群改进并发；
▶︎ 读写分别：数据库的读写分别；
▶︎ 运用反向署理和 cdn 加速；
▶︎ 运用分布式文件和分布式数据库。
单体架构的运用比较简单安置、检验， 在项目的初期，单体运用能够很好地工作。可是，跟着需求的不断添加， 越来越多的人参加开发团队，代码库也在飞速地膨胀。
慢慢地，单体运用变得越来越臃肿，可维护性、灵活性逐步下降，维护本钱越来越高。全体来说，单体架构运用或许会有这些缺点：凌乱性高、技术债务堆集、安置频率低、可靠性差、扩展才华受限并且或许阻碍技术创新。
分布式
为了处理上面提到的这些缺点，我们需求对系统按照业务功用模块拆分，将各个模块服务化，变成一个分布式系统。
业务模块分别安置在不同的服务器上，各个业务模块之间通过接口进行数据交互。该架构相关于单体架构来说，这种架构供应了负载均衡的才华，大大前进了系统负载才华，处理了网站高并发的需求。别的还有以下特色：
| 下降耦合度：把模块拆分，运用接口通讯，下降模块之间的耦合度。 职责清楚：把项目拆分红若干个子项目，不同的团队担任不同的子项目。 扩展便当：添加功用时只需求再添加一个子项目，调用其他系统的接口就能够。 安置便当：能够灵活地进行分布式安置。 前进代码的复用性：比如 Service 层，假定不选用分布式 rest 服务方法架构就会在手机 Wap 商城，微信商城，PC，Android，iOS 每个端都要写一个 Service 层逻辑，开发量大，难以维护一起晋级，这时分就能够选用分布式 rest 服务方法，共用一个 service 层。 *缺点：系统之间的交互要运用远程通讯，接口开发增大作业量，可是利大于弊。 |
|---|
微服务
跟着业务方式越来越凌乱，订单、产品、库存、价格等各个模块都很深化，比如价格区别会员等级，访问途径（app 仍是 PC），出售方法（团购仍是一般）等，还有许多的价格促销。
这些规则很凌乱，简单互相冲突。我们需求把涣散到各个业务的价格逻辑进行一起处理，以基础价格服务的方法透明地供应给上层运用，变成一个微内核的服务化架构，即微服务。
微服务的特色显着：易于开发与维护、单个微服务发动较快、部分批改简单安置、技术栈也不受限制。
可是，微服务虽然有许多吸引人的当地，但它并不是免费的午饭，运用它或许面临这些应战：
| 运维要求较高：更多的服务意味着更多的运维投入。在单体架构中，只需求确保一个运用的正常工作。而在微服务中，需求确保几十乃至几百个服务的正常工作与协作，这给运维带来了很大的应战。 分布式固有的凌乱性：运用微服务构建的是分布式系统。关于一个分布式系统，系统容错、网络推迟、分布式业务等都会带来巨大的应战。 接口调整本钱高：微服务之间通过接口进行通讯。假定批改某一个微服务的API，或许全部运用了该接口的微服务都需求做调整。 重复劳动：许多服务或许都会运用到相同的功用，而这个功用并没有到达分解为一个微服务的程度，这个时分，或许各个服务都会开发这一功用，从而导致代码重复。尽管能够运用同享库来处理这个问题（例如能够将这个功用封装成公共组件，需求该功用的微服务引用该组件），但同享库在多语言环境下就不必定行得通了。 |
|---|
我们掌握前人总结的阅历，让我们站在巨人的肩膀上高山远瞩。《架构真经》这本书简略论说了架构规划的一些常用的原则。下面我结合原著作，同享15个具有普适价值架构原则：
N+1规划 ：开发的系统在产生毛病时，至少有一个冗余的实例
广泛地运用在从数据中心规划到运用服务的安置：
▶︎ 在产生毛病时，系统至少要有一个冗余的实例。
▶︎ 有必要确保一个为自己，一个为客户、 一个为失利。
回滚规划 ：确保系统能够向后兼容
▶︎ 假定好久才华批改服务，那么就要在必定的时间范围内结束回滚。
▶︎ 灾难性的事端，例如损坏客户数据，往往在安置后好几天才出现。
▶︎ 系统最好按照预先的规划，通过发布或回滚处理问题。
通过版别化方法结束回滚规划，一旦产生灾难级别的毛病能够通过回滚到最近版原本恢复服务。
禁用规划（功用开关、降级开关）：能够关闭任何发布功用
当规划系统，特别是与其他系统或服务通讯的高危险系统时，要确保这些系统能够通过开关来禁用。这将为批改服务供应额定的时间，一起确保系统不因为差错引起怪异需求而宕机。
降级开关通过配备中心会集化处理，例如：apollo 配备中心，通过推送机制把开关推送到各个运用服务。
监控规划：在规划阶段就要考虑监控，而不是在安置结束后
▶︎ 通过监控发现系统的可用性问题。
▶︎ 通过监控使系统自我确诊、自我批改成为或许。
▶︎ 通过监控确认系统可预留空间的运用情况。
▶︎ 通过监控掌握系统之间的交互联络，发现瓶颈 。
假定监控做得好，不仅能发现服务的死活，查看日志文件，还能收集系统相关的数据，点评终端用户的响应时间。假定系统和运用在规划和构建时就考虑好监控，那么即使不能自我批改，也至少能够自我确诊。
多活数据中心规划
▶︎ 数据是否悉数会集在一个数据中心？
▶︎ 读写是否分别？
▶︎ 是否全部的客户信息都同享同一个数据结构？
▶︎ 服务调用是否答应延时的存在？
选用成熟的技术
工程师倾向于学习和施行性感时髦的新技术。因为新技术能够下降本钱、削减产品上市时间、前进功用。不幸的是，新技术也往往有较高的毛病率。假定把新技术运用在架构的要害部分，或许会对可用性产生显着的影响。
最好争夺在多数人选用该技术的时分进入，先把新技术用在对可用性要求不高的功用上，一旦证明它能够可靠地处理日常的买卖，再将此技术移植到要害任务范畴中去。
毛病隔绝
避免单一业务占用悉数资源，避免业务之间的互相影响。机房隔绝避免单点毛病。两个重要原则：
▶︎ 不同享原则：抱负情况是负载均衡、网络前端、运用服务器、数据库，绝不同享任何服务、硬件和软件。
▶︎ 不跨区原则： 不同隔绝区之间无通讯，全部服务调用有必要产生在同一个毛病隔绝区。
水平扩展
什么是水平可扩展？途径的水平扩展是指跟着业务的打开，当需求扩大途径的服务才华时，不必重构软件系统，通过添加新的设备来满足业务增加的需求。
| X轴扩展：服务器拆分。途径的服务才华能够在不改动服务的情况下，通过添加硬件设备来结束扩容。 Y轴扩展：数据库拆分。途径的服务才华通过不断地分解和安置服务来结束扩容。 Z轴扩展：功用拆分。途径的服务才华能够按照客户不断分解和安置来机器 结束容量的扩展。（比如按用户 uid 来分表分库等） |
|---|
非中心则购买
工程师往往有自己研发全部系统的冲动。假定运用云服务器，主张直接运用云服务相关产品比如日志系统，能够直接运用日志服务。
▶︎ 系统研发要投入资源，系统维护更要长期投入。
▶︎ 影响中心产品到商场的速度。
▶︎ 假定能够构成差异化的竞赛优势，那么自己做，否则外购。
运用产品化硬件
在大多数情况下，便宜的是最好的。标准、低本钱、可交换、易于产品化是产品化硬件的特征。
假定架构规划得好，就能够通过购买最便宜的服务器轻松地结束水平扩展，条件是全部产品化硬件的总本钱要低过高端硬件的总本钱。
快速迭代
这里有三个要点：
▶︎ 小构建：小构建的本钱较低，能够确保投资能够产生价值。
▶︎ 小发布：发布的失利率与改变数量相关，小发布失利率较低。
▶︎ 快试错：可依商场反馈，快速迭代，加速TTM，优化用户领会。
快速迭代需求完善的运维东西，比如从 cmdb、持续集成东西、监控等等。
异步规划
同步系统中单个子系统出现毛病会对整单个系带来影响。这里常有2个现象：
▶︎ 同步系统中功用最慢的子系统，成为整单个系功用的瓶颈。
▶︎ 同步系统中扩展性最差的子系统，是整单个系扩展的瓶颈。
无情况规划
无情况定义： 是运用服务工作的实例不会在本地存储需求耐久化的数据，并且多个实例关于同一个请求响应的结果是完全一起的。比如单实例的 mysql，zookeeper 集群是有情况，而相似单纯 tomcat 服务是无情况的。
无情况的系统更利于扩展，更利于做负载均衡。情况是系统的吞吐量、易用性、可用性、功用和可扩展性的大敌，要尽最大或许避免。
前瞻性规划
▶︎ Now：现在正运用系统的架构、规划、才华、功用和扩展性。
▶︎ Now+1: 下一代预研系统的架构、规划、才华、功用和扩展性。
▶︎ Now+2: 下一代规划系统的架构、规划、才华、功用和扩展性。
自动化
规划和构建自动化的进程。假定机器能够做，就不要依托于人。人常犯差错，更令人沮丧的是，他们往往会以不同的方法屡次犯同样的差错。
最终，想跟各位同享几个我亲身总结的架构规划误区，期望能够给你一些构思。
| 开高走落不到实处。 遗漏要害性捆绑与非功用需求。 为虚无的未来埋单而过度规划。 过早做出要害性抉择计划。 客户说啥就是啥成为传话筒。 静心干活儿缺少前瞻性。 架构规划还要考虑系统可测性。 架构规划不要试图一步到位。 |
|---|
误区1——架构专门由架构师来做，业务开发人员无需关注
架构得再好，毕竟仍是需求代码来落地，并且组织越大这个落地的难度越大。不单单是系统架构，每个处理计划每个项目也由自己的架构，如分层、规划方式等。
假定每一块砖瓦不可坚固，那么整单个系仍是会由坍塌的危险。所谓“千里之堤，溃于蚁穴”。
误区2——架构师确认了架构蓝图之后任务就结束了
架构不是“海市蜃楼”，毕竟仍是要落地的，可是架构师完全不去深化到第一线怎样知道“地”在哪、怎样才华落得稳稳当当？
误区3——不做出完美的架构规划不开工
世上没有最好架构，只有最适宜的架构，不要试图一步到位。我们需求的不是一会儿造出一辆轿车，而是从单轮车 –> 自行车 –> 摩托车，最终再到轿车。
你梦想一下2年后才华造出的产品，最初商场还存在吗？
误区4—— 为虚无的未来埋单而过度规划
在创业公司初期，业务场景和需求鸿沟很难掌握，产品需求快速迭代和变现，需求一再更新，这个时分需求的是快速结束。不要过多考虑未来的扩展，说不定功用做完，效果欠好就无用了。
假定业务方式和运用场景鸿沟都已经比较清楚，是应该适当的考虑未来的扩展性规划。
误区5——一味跟随大公司的处理计划
因为大公司巨大成功的光环效应，再加上从大公司挖来的技术高手的影响，网站在谈论架构抉择计划时，最有说服力的一句话就成了“xx就是这么搞的”。
大公司的阅历和成功方式当然重要，值得学习学习。但假定因此而变得盲从，就失去了坚持自我的勇气，在架构演化的道路上迟早会迷路。
误区6——为了技术而技术
技术是为业务而存在的，除此毫无意义。在技术选型和架构规划中，脱离网站业务打开的实践，一味寻求时髦的新技术，或许会将技术打开引进高低小道，架构之路越走越难。
考虑结束本钱、时间、人员等各方面都要归纳考虑。抱负与实际需求折中。
以上就是我同享的悉数内容，假定觉得内容有用，欢迎同享转发~
-End-
原创作者｜黄规速
本栏目将持续带来腾讯工程师的架构规划阅历干货。
你还想看腾讯工程师同享哪些业务的架构规划阅历、聊什么架构规划知识？欢迎在腾讯云开发者公众号留言。我们将为1位提案供应者送出腾讯定制毛毯。8月9日正午12点开奖。
