开发架构

文章目录

开发架构
- 概述
- 前言
- 互联网发展特点
- 单体架构
- 面向服务架构(SOA)
- 水平分层架构
- 微服务架构：水平拆分+垂直拆分
- 服务网格架构
- 中台架构
- 云原生架构
- Serverless 架构
- 小结
- 公众号

概述

简述了互联网业务发展的特点，重点阐述了从单体架构到SOA架构、微服务架构、服务网格架构的架构演进；简要介绍了中台架构、云原生架构、Serverless架构；架构演进背后的哲学：拆分；最合适的架构就是在各方面场景下折中(Balance)的结果；架构设计的终极之道：降本增效。

前言

要讲总体架构中的开发架构，我觉得以架构演进这个切入点来讲是非常合适的；因为要进行开发首先就是要进行架构设计、技术选型等；同时不同的架构设计也和我们的开发模式都是紧密相关的；

当然，从整体的开发框构来说，除了架构设计，还会有很多其它的相关核心要点：如相关核心技术：高可用、高性能、高并发设计、服务幂等、无状态设计等；相关核心系统：分布式缓存、消息队列、数据存储等中间件；相关服务治理技术等：熔断、限流、服务注册与发现等；这些可以另外以相关专题来进行学习，本文主要还是以架构的演进以及其演进背后的道来进行分享。

整个架构设计是在不断演进的，这演进背后的道是什么，宏观上来说就是：满足企业级的发展；那么在技术侧有没有合适的道呢？

互联网发展特点

首先我们来分析一下业务发展的一些特点；

业务功能越来越多、越来越复杂
- 从静态化、到半静态、到动态
万物互联数据量越来越大
请求量越来越大，更高的用户体验要求
业务快速迭代、持续交付的能力
- 做架构的目的就是为了让产品能够快速迭代、快速交付，能做到降本提效
- 降低人力成本、机器成本；提高开发效率、测试效率、运维效率。

随着业务的变化，这些也在不断的推动着架构不断的一个演进。

单体架构

最开始，创业初期，业务量小，业务相对简单，要快速构建。

如：系统有用户、商品、交易三个功能模块，直接用一个 process + db ，就可以满足公司的需求，这其实就是单体架构；这也能很好的满足你的业务。

这个阶段：优先发展业务，先解决生存的问题。

扩展方式

集群部署

常用的高可用部署方案

通过 DNS 解析域名，指向一个 VIP (虚IP) ，VIP 背后对应的是 LVS 所在的服务器；
- VIP：就是一个未分配给真实主机的IP ，服务器的主机除了有一个真实IP外还有一个虚IP，使用这两个IP中的任意一个都可以连接到这台主机，当服务器发生故障无法对外提供服务时，动态将这个虚IP切换到备用主机。
四层(LVS/F5) + 七层(nginx) 的负载均衡方案；
- 避免单点故障，一般部署两台 LVS 做热备，通过 keepalive 高可用；
- nginx 可横向扩展
后台服务集群部署

        client -> DNS|VIP/           \
LVS <-keepalive-> LVS\            /nginx  nginx nginx/            \
service service service\            /DB + Cache

适用场景

业务场景简单、功能不复杂、研发人员较少(O2O)
创业公司初期
性能要求极其苛刻
- 常用性能指标：吞吐量、响应延时；

缺点

系统耦合性高
技术选型单一
开发效率越来越低下

随着业务的发展，无法满足业务需求（性能瓶颈、快速迭代、持续交付等），这时候可能就需要将单体拆分成多个服务；

破局时机：当迭代速度很慢时；

方法：拆分。

如何破局：

数据库存储量大破局思路：分库（垂直拆分）、分表（水平拆分）；
- 如：一个库中的数据太多了；分库：将一个 DB 拆分成：用户库、商品库、交易库；
- 如：一张表中的数据太多了；分表：将用户表(user)，按 user_id % n ，将一张用户表拆分成 n 张表；
架构同理
- 垂直方向拆分（业务维度）
- 水平方向拆分（功能维度）

架构演进背后的哲学其实就是拆分；可以按业务在垂直方向拆、也可以按功能在水平方向拆；

面向服务架构(SOA)

面向服务的拆分：按业务来进行拆分，将一个 process 拆成多个 process 。

如：将用户、商品、交易拆分成三个进程(process) ；

SOA定义

组件模型
不同功能单元(服务)通过定义的良好接口关联
接口采用中立的方式定义，独立于硬件平台、操作系统和编程语言

面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构件在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

架构特点：垂直拆分

多个独立服务
通过ESB交互

SOA缺点：

业务垂直方向拆分，但每个服务还是单体
对ESB严重依赖

水平分层架构

按水平方向拆分成多个独立进程(process)

网关层
业务逻辑层
数据访问层

每层逻辑解耦。

微服务架构：水平拆分+垂直拆分

微服务架构：既进行水平拆分，又进行垂直拆分；

微服务架构包括：服务的功能设计和服务的治理两部分：

服务的功能设计：包含了业务本身的功能；负责业务本身的需求；
服务的治理：限流、降级、熔断、服务注册和发现；负责服务治理的需求；

本质：

2个维度拆分
- 一个是垂直拆分，按业务拆分，拆分较难，如拆分成商品服务，可能需要继续进行拆分：读拆分成一个服务、写拆分成一个服务，因为可能读请求让写请求无法被处理；是否需要继续拆分需要依据具体业务；
- 一个是水平拆分
业务架构
- 微服务拆分难点在业务拆分，微服务是一种业务架构
康威定律是马尔文·康威1967提出的：“设计系统的架构受制于产生这些设计的组织的沟通结构。”通俗的来讲：产品必然是其（人员）组织沟通结构的缩影。
组织架构
- 按事业部性质划分的组织架构：如划分为：房产事业部、招聘事业部、二手车事业部；（微服务类似这种）
- 按职能性质划分的组织架构：如划分为：研发部、产品部、运维部等
微服务一是一种业务架构，二是一种按照事业部组织的组织架构；

适用层面：

需求层面
- 要求需求变化比较频繁；
- 需求变化不频繁，如内部OA、ERP等系统，微服务架构意义不大；
性能层面
- 性能的两个指标：吞吐量、平均响应延时
- 使用微服务架构：吞吐量会变高（每一层都可以横向扩展），平均响应延时也会变高（拆分成了网关层、业务逻辑层等）
- 部分时间要求极其苛刻的场景不适用微服务架构，如：交易场景中的量化交易、高频交易等；
数据一致性层面
- 两种一致性：强一致性、最终一致性，
- 使用微服务架构解决的是最终一致性；
- 数据库拆分成多个DB，本地事务是失效的；只能使用分布式事务来处理，使用分布式事务能解决强一致性，但会造成吞吐量低的问题；一般更多的是用分布式事务解决最终一致性问题；

目的：

项目快速迭代
项目持续交付
如果项目需求没有快速迭代和持续交付的需求，不需要使用微服务架构；

一句话总结：使用微服务架构就是为了降本增效；

服务网格架构

服务网格架构：包括服务功能拆分 + 服务治理拆分。

微服务架构不是银弹：

业务逻辑层需要关注服务间通信，会使得业务迭代速度变慢；
基础设施组件升级困难，影响基础设施团队的交付能力和交付速度；
多编程语言之间“通信”问题，业务每种语言一套基础设施，成本大；

如何让业务逻辑层只关注业务部分，不需要再关注通信组件部分，便有了Service Mesh架构；

业务团队专注于业务逻辑本身，
服务通信交给基础设施团队，
物理解耦业务研发团队和基础设施团队，
一套基础设施支持多语言开发，
基础设施能力从应用程序下推，
真正做到快速迭代，持续交付。

中台架构

中台虽然是一种架构，但更多的是一种组织模式，或者说是一种组织架构；首先是一种组织架构，其次才是业务架构；业务架构在落地的时候，可以采用服务网格架构、微服务架构等。

中台架构和以上的架构不是同一个维度的东西。

云原生架构

云原生架构解决的是一个什么问题；前面几种架构更多的是从我们的架构设计本身的角度上来讲的；
云原生架构不是聚焦在架构设计侧，而是聚焦在运维侧；也就是说中台架构在落地是可以用（微服务架构等），这些架构最终在运行的时候是运行在物理机|虚拟机上，也可以运行在docker容器上，这个容器对我们来说就是一个环境，这个环境上就是我们的云原生架构；也就是说这些架构运行在docker弹性云上，就可以认为就是一个云原生架构；

中台架构实现可以用微服务架构等架构实现，最终运行在容器云上就是云原生架构；

最本质的区别是：前面几个 focus 在架构侧，云原生架构 focus 在运维侧。

Serverless 架构

它做的一个事情就是让你无需关注你的服务器，只需要写业务逻辑就可以了；
这个本质上也是一种拆分；对你来说，你只能看到它的业务本身。

小结

架构演进的原因：需求

架构完整解决方案：

具体业务场景、人员场景、时间场景、金钱场景等各种场景，
架构如何选型，
架构如何设计，
架构如何折中，
架构线上问题如何解决。

场景驱动架构不断演进：

场景包括：业务场景、人员场景、时间场景、金钱场景等
最合适的架构就是各方面折中(Balance)的结果；
合适的架构就是根据业务的适度超前的架构；
适度超前就是满足业务半年到一年的需求。

架构背后哲学思考

为什么要这样设计
其他方案为啥不优雅

整个架构设计是不在不断演进的，这演进背后的道是什么？

宏观上来说就是：满足企业级的发展；
在技术侧的道就是：拆分。

架构演进背后的哲学：拆分

垂直拆分
水平拆分

架构设计终极之道：降本增效。

公众号

程序员整体架构之开发架构相关推荐

零架构项目经验的程序员，如何升级成架构师
先说目前关于架构师的一些是实际情况. 1 要成为Java架构师,单纯靠学知识一定不行,得靠在项目里积累经验. 2 如何判断程序员是否已经成为java架构师?不是看程序员掌握的技能,更不是看程序员干的活 ...
GPU Saturday技术沙龙：OpenCL程序员眼中的下一代APU架构
摘要:GPU Saturday技术沙龙在北京·3WCoffee成功举办.本次活动邀请AMD资深技术人员及清华大学项目研究员就AMD最新的GCN架构.GPU加速计算在挖掘比特币.典型图像算法.深度神经网 ...
Java程序员如何成为优秀的架构师
怎样学习才能从一名Java初级程序员成长为一名合格的架构师,或者说一名合格的架构师应该有怎样的技术知识体系,这是不仅一个刚刚踏入职场的初级程序员也是工作三五年之后开始迷茫的老程序员经常会问到的问题. ...
程序员好几年才能成为架构师_成为更好的企业架构师
程序员好几年才能成为架构师企业架构师似乎越来越多地参与"尝试新事物"或推翻技术或实施建议(否定命令),而不必费劲或无需编写任何代码. 我已经在很多地方观察到了这一点,无论是与建筑 ...
5分钟弄懂程序员的如何升级到架构师。
对我们程序员来说,发展的途径要么是走管理岗,从开发升级到项目经理甚至是部门经理:要么走技术升级路线.不过在技术路线方面,无法升级到架构师的程序员不在少数.一方面,在不少公司的高级开发岗位上,无法让程序 ...
30kJava程序员升为全栈架构师的晋升之路
当下当一个Java程序员是有前途的,你对这句话不持反对的意见吧.Java作为市场上最流行.应用最广泛的编程语言之一,当下学Java成为一个Java程序员当然是有前途的.但是作为一个Java程序员,也有 ...
Java程序员如何转Android开发
最近几日偷偷的发现部分Java程序员想转安卓开发,故此加紧补充知识,为大家搜集资料,积极整理前人的经验,希望可以给正处于困惑中的你,带来些许的帮助. 啰哩啰嗦的说说Java和Android程序的区别: ...
「程序员的思维修炼——开发认知潜能的九堂课」读书笔记
书名:程序员的思维修炼--开发认知潜能的九堂课作者:(美) 亨特 (Andy Hunt) 译者:崔康关于本书本书从德雷福斯模型入手,阐释了程序工程师发展的五个阶段:接着从阶段间的特征中引出 L ...
java程序员如何进行物联网开发
树莓派作为它作为全新的物联网开发方式,其的家族越来越强大,从1A到当前的4B系统列为主,另外还有zero系列,计算模块,不久前推出了pi pico开发板,其价格比较低,适合各种人学习从儿童编程到开发者 ...
程序员为维持游戏开发被迫炒股，一年内反赚1600万；雷军退任天星银行董事会主席；华为开源Karmada将捐赠CNCF...
点击上方 "编程技术圈"关注, 星标或置顶一起成长后台回复"大礼包"有惊喜礼包! 每日英文 Your life only lasts for a few de ...

程序员整体架构之开发架构