软件架构的演进之路

软件架构的演进之路

架构演进之路

1. 单体架构

2. 水平分层架构

3. 面向服务架构（SOA）

4. 微服务架构

5. 服务 格架构（Service Mesh）

架构是什么？

事实上“架构”这一词在软件还没出生之前就已经存在了，这个词最早是用于建筑行业的（“搬砖”也和建筑行业有关，果然是两个形影不离的好哥们）。古人使用“搆驾”或者是“架构”一词，来从宏观上表述一种”规模“或是其“规划设计”，所以现在我们用“架构”一词来表述或者翻译其含义。

一言以蔽之，所谓的软件架构是指软件整体结构与组件的“顶层抽象描述”。其作用是用于指导整个软件系统各方面的设计。

---

So，在我们实际工作中落地，则需面对一个应用场景，从顶层设计出一个好的总体解决方案，将其进行抽象的描述，评审方案的合理性与当前和后期规划的业务场景、技术团队能力是否贴合，之后将其拆分成一个一个点落地实施。 而提升架构的高度，仅寄希望于代码层级的落地执行力是不够的的。对业务的洞察力、对整个产品的技术规划与总体视野与格局是相当重要的，这些是我们在不断的业务技术积累中需要不断提高的地方。

架构的演进阶段

人与人在 络上的交互形式在不断发生变化

1. 在门户 站时代，仅仅将部分内容在线化，同时一个内容发布中心对应多个点进行广播式传播。
2. 在微博、Twitter出现时，我们以互动为中心，通过“关注”功能，产生了相应的 络效应，讨论的人越多，浏览量越大，让交流与内容数据的积累有了自成长的可能。
3. 在微信、Facebook出现时，我们通过群组、朋友圈等功能把“关注”这种多对一关系，变成了多对多关系，形成了更加复杂的 络交互，人与数据的 络更密更复杂，才能用更高效的方式实现原来很难实现的事情。
4. 在抖音、快手等短视频直播平台出现后，在人与数据形成的这些 络上我们需要支持更加复杂的内容传播，同时还需要保证更多用户的实时稳定在线、更大量级的数据传播、更短的延时，才能保证用户体验。

发展趋势

? 业务功能：越来越多、越来越复杂。

? 数据量：万物互联后，数据量越来越大。

? 请求量：越来越大，需满足更多更高的用户体验要求。

? 持续交付能力：业务迭代速度加快，交付能力需要提升。

架构的目的不是为了秀操作，是为了让产品与业务能够快速迭代与持续交付，达到降本提效的作用，降低人力、机器硬件成本，提升开发、测试、运维效率

架构演进

? 单体架构（monoliths）–>

? 水平分层架构（horizontal layered）–>

? 面向服务架构（SOA）–>

? 微服务架构（MicroServices）–>

? 服务 格架构（Service Mesh）

（一）单体架构

定义

? 单个Jar/war包部署在容器中，所有功能模块耦合在单个目录层级的java代码中

单体架构

优点

开发、测试、部署、扩展简单

适用场景

? 业务场景简单、功能不复杂、研发人员较少

? 公司初创、产品初立时的快速原型

? 性能要求（平均相应延迟）极其苛刻的场景

缺点

? 技术选型单一

? 系统耦合性高

? 随着功能越来越多，开发效率会越来越低，迭代周期会越来越长，更新成本会越来越大

单体架构扩展

同时单体还可横向扩展，就是多增加几台服务器一起提供相同的服务

单体架构(横向扩展)

（二）水平分层架构

定义

? 在水平方向逻辑划分多个层的基础上物理分成多个独立进程

? 每一层逻辑解耦（每一层有独立的职责干具体的事情）

常用分层

? 关层

? 业务逻辑层

? 数据访问层

? 数据存储层

? …

水平分层架构

水平分层各层功能

关层功能

? 统一认证、请求鉴权

? 数据完整性检查（数据包检查）

? 静态/动态路由转发

? 协议转化、转发、包装

? 服务的限流、降级、熔断

? 日志监控

? 路径重写

? …

业务逻辑层功能

? 业务规则的制定、业务流程的实现等与业务需求有关的系统功能

数据访问层功能

? 增删改查（CRUD）

? 数据映射，对象关系映射ORM

? 乐观锁并发

? 延时加载

? 持久化透明对象

? 命令查询职责分离（CQRS）

? 读写分离

? 分库分表

? 屏蔽底层存储差异

? …

分层过多会造成的问题

? 请求路径变多变长

? 平均响应时延变长

? 定位问题的难度变大

? 维护成本增加

公 上动静分离水平分层架构

? DNS域名解析

? 静态资源获取

? 动态接口数据获取

水平分层，动静分离

水平分层待改进的部分

就目前而言，每层的粒度过粗，还是有大量的逻辑耦合在一起

（三）SOA面向服务架构

定义

? 面向服务的架构（SOA）是一个组件模型。

? 将不同功能服务通过定义良好的接口与协议进行关联。

? 各接口独立于硬件平台、操作系统和编程语言。

SOA架构

特点

? 服务按业务进行垂直拆分

? 服务之间松耦合

? 服务标准化、可重用性高

? 精确定义的服务契约、支持各种消息协议

? 通过企业服务总线ESB进行交互

缺点

? 业务垂直拆分，每个服务还是单体

? 对ESB严重依赖

（四）微服务架构

我对微服务的一个通俗理解是服务的“水平 + 垂直”拆分

理念

? 一系列小服务的组合

? 可在在自身独立的进程中运行

? 各服务围绕业务进行拆分

? 各服务能独立的部署

? 可以用不同语言编写、不同介质存储数据

微服务架构

微调

业务逻辑层粒度比较粗，所有业务逻辑耦合在一个物理进程内部迭代效率低下。我们可以把将一些公共服务下沉出来公共逻辑层组件化、抽成lib或服务化，提供通用的兼容性接口

微服务架构

微服务一般的应用场景

? 需求层面，适用于需求变化比较平凡，需要快速迭代

? 性能层面，适用于吞吐量高（容易横向扩展），平均响应时间短的场景

? 数据一致性层面，适用于解决数据最终一致性问题

? 持续交互层面，支持项目的快速迭代、持续交付

---

我的经验是：业务的垂直拆分难于技术的水平拆分，微服务使用的技术并不是很难，关键是在于对业务理解后的业务服务模块的治理与拆分行为

微服务也不是万能的

1. 业务逻辑服务，需要关注服务间通信，约束业务代码迭代速度
2. 通信逻辑组件与基础设施组件升级困难，即基础设施团队或底层架构团队的交付能力和速度约束业务团队的产品迭代能力
3. 多语言、跨语言之间通信成本太高，即每种语言一套通信组件逻辑/基础设施

微服务

---

微服务架构的演进

基于上面的问题我们可以做的是什么呢？很明显，即下沉通信组件逻辑。服务通信交给基础设施团队，从而物理解耦业务研发团队和基础设施团队。基于使用场景和公司实际技术能力打造一套基础设施支持多语言开发。这样，才能在异构的企业系统环境中提高快速迭代、持续交付的能力

（五）服务 格架构（Service Mesh）

ok，我们来解决上面微服务架构未解决的问题

定义

? 作为基础服务/设施层，用于处理服务间通信

? 云原生应用有着复杂的服务拓扑交互，服务 格在这些复杂的通信中实现请求的可靠传递

实践中

通常实现为一组轻量级的 络代理，一般与应用程序服务部署在一台物理设备上，在通信层面对应用程序透明

? 基础服务/设施下沉为一个独立的服务（sidecar）

? 应用程序和sidecar一般部署在一台物理机器上，可以解决应用程序和自身sidecar的通信问题

服务 格架构

优点

? 基础服务/设施独立进程、独立升级

? 业务团队专注于业务逻辑本身

? 根据能力可实现一套基础服务/设施可支持多语言开发

? 业务团队和基础设施团队物理解耦

---

这是笔者的第一篇文章，后面会根据小伙伴们的反馈不断优化、改进、定期更新，喜欢的小伙伴们记得收藏、点赞加个关注吧~~~~