开发架构
文章目录
开发架构概述前言互联网发展特点单体架构面向服务架构(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)的结果；合适的架构就是根据业务的适度超前的架构；适度超前就是满足业务半年到一年的需求。
架构背后哲学思考
为什么要这样设计其他方案为啥不优雅
整个架构设计是不在不断演进的，这演进背后的道是什么？
宏观上来说就是：满足企业级的发展；在技术侧的道就是：拆分。
架构演进背后的哲学：拆分
垂直拆分水平拆分
架构设计终极之道：降本增效。
