软件架构的演进之路
架构演进之路
1. 单体架构
2. 水平分层架构
3. 面向做事架构（SOA）
4. 微做事架构
5. 做事网格架构（Service Mesh）
架构是什么？事实上“架构”这一词在软件还没出生之前就已经存在了，这个词最早是用于建筑行业的（“搬砖”也和建筑行业有关，果真是两个形影相随的好哥们）。古人利用“搆驾”或者是“架构”一词，来从宏不雅观上表述一种”规模“或是其“方案设计”，以是现在我们用“架构”一词来表述或者翻译其含义。
一言以蔽之，所谓的软件架构是指软件整体构造与组件的“顶层抽象描述”。其浸染是用于辅导全体软件系统各方面的设计。
So，在我们实际事情中落地，则需面对一个运用处景，从顶层设计出一个好的总体办理方案，将其进行抽象的描述，评审方案的合理性与当前和后期方案的业务场景、技能团队能力是否贴合，之后将其拆分成一个一个点落地履行。 而提升架构的高度，仅寄希望于代码层级的落地实行力是不足的的。对业务的洞察力、对全体产品的技能方案与总体视野与格局是相称主要的，这些是我们在不断的业务技能积累中须要不断提高的地方。
架构的演进阶段好的架构是要能贴合实际运用处景同时能有一定的扩展性能支撑后期的方案。以是他不纯挚是一个技能命题。业务的发展才是驱动架构演进的动力来源，实际要面对的业务场景匆匆使了技能的创新迭代
人与人在网络上的交互形式在不断发生变革在门户网站时期，仅仅将部分内容在线化，同时一个内容发布中央对应多个点进行广播式传播。在微博、Twitter涌现时，我们以互动为中央，通过“关注”功能，产生了相应的网络效应，谈论的人越多，浏览量越大，让互换与内容数据的积累有了自发展的可能。在微信、Facebook涌现时，我们通过群组、朋友圈等功能把“关注”这种多对一关系，变成了多对多关系，形成了更加繁芜的网络交互，人与数据的网络更密更繁芜，才能用更高效的办法实现原来很难实现的事情。在抖音、快手等短***直播平台涌现后，在人与数据形成的这些网络上我们须要支持更加繁芜的内容传播，同时还须要担保更多用户的实时稳定在线、更大量级的数据传播、更短的延时，才能担保用户体验。发展趋势• 业务功能：越来越多、越来越繁芜。
• 数据量：万物互联后，数据量越来越大。
• 要求量：越来越大，需知足更多更高的用户体验哀求。
• 持续交付能力：业务迭代速率加快，交付能力须要提升。
架构的目的不是为了秀操作，是为了让产品与业务能够快速迭代与持续交付，达到降本提效的浸染，降落人力、机器硬件本钱，提升开拓、测试、运维效率
架构演进• 单体架构（monoliths）-->
• 水平分层架构（horizontal layered）-->
• 面向做事架构（SOA）-->
• 微做事架构（MicroServices）-->
• 做事网格架构（Service Mesh）
（一）单体架构定义• 单个Jar/war包支配在容器中，所有功能模块耦合在单个目录层级的java代码中
单体架构
优点开拓、测试、支配、扩展大略
适用场景• 业务场景大略、功能不繁芜、研发职员较少
• 公司初创、产品初立时的快速原型
• 性能哀求（均匀相应延迟）极其苛刻的场景
缺陷• 技能选型单一
• 系统耦合性高
• 随着功能越来越多，开拓效率会越来越低，迭代周期会越来越长，更新本钱会越来越大
单体架构扩展同时单体还可横向扩展，便是多增加几台做事器一起供应相同的做事
单体架构(横向扩展)
（二）水平分层架构定义• 在水平方向逻辑划分多个层的根本上物理分成多个独立进程
• 每一层逻辑解耦（每一层有独立的职责干详细的事情）
常用分层• 网关层
• 业务逻辑层
• 数据访问层
• 数据存储层
• ...
水平分层架构
水平分层各层功能网关层功能• 统一认证、要求鉴权
• 数据完全性检讨（数据包检讨）
• 静态/动态路由转发
• 协议转化、转发、包装
• 做事的限流、降级、熔断
• 日志监控
• 路径重写
• ...
业务逻辑层功能• 业务规则的制订、业务流程的实现等与业务需求有关的系统功能
数据访问层功能• 增编削查（CRUD）
• 数据映射，工具关系映射ORM
• 乐不雅观锁并发
• 延时加载
• 持久化透明工具
• 命令查询职责分离（CQRS）
• 读写分离
• 分库分表
• 屏蔽底层存储差异
• ...
分层过多会造成的问题• 要求路径变多变长
• 均匀相应时延变长
• 定位问题的难度变大
• 掩护本钱增加
公网上动静分离水平分层架构• DNS域名解析
• 静态资源获取
• 动态接口数据获取
水平分层，动静分离
水平分层待改进的部分就目前而言，每层的粒度过粗，还是有大量的逻辑耦合在一起
（三）SOA面向做事架构定义• 面向做事的架构（SOA）是一个组件模型。
• 将不同功能做事通过定义良好的接口与协议进行关联。
• 各接口独立于硬件平台、操作系统和编程措辞。
SOA架构
特点• 做事按业务进行垂直拆分
• 做事之间松耦合
• 做事标准化、可重用性高
• 精确定义的做事左券、支持各种协议
• 通过企业做事总线ESB进行交互
缺陷• 业务垂直拆分，每个做事还是单体
• 对ESB严重依赖
（四）微做事架构我对微做事的一个普通理解是做事的“水平 + 垂直”拆分
理念• 一系列小做事的组合
• 可在在自身独立的进程中运行
• 各做事环绕业务进行拆分
• 各做事能独立的支配
• 可以用不同措辞编写、不同介质存储数据
微做事架构
微调业务逻辑层粒度比较粗，所有业务逻辑耦合在一个物理进程内部迭代效率低下。我们可以把将一些公共做事下沉出来公共逻辑层组件化、抽成lib或做事化，供应通用的兼容性接口
微做事架构
微做事一样平常的运用处景• 需求层面，适用于需求变革比较平凡，须要快速迭代
• 性能层面，适用于吞吐量高（随意马虎横向扩展），均匀相应韶光短的场景
• 数据同等性层面，适用于办理数据终极同等性问题
• 持续交互层面，支持项目的快速迭代、持续交付
我的履历是：业务的垂直拆分难于技能的水平拆分，微做事利用的技能并不是很难，关键是在于对业务理解后的业务做事模块的管理与拆分行为
微做事也不是万能的业务逻辑做事，须要关注做事间通信，约束业务代码迭代速率通信逻辑组件与根本举动步伐组件升级困难，即根本举动步伐团队或底层架构团队的交付能力和速率约束业务团队的产品迭代能力多措辞、跨措辞之间通信本钱太高，即每种措辞一套通信组件逻辑/根本举动步伐微做事
微做事架构的演进基于上面的问题我们可以做的是什么呢？很明显，即下沉通信组件逻辑。做事通信交给根本举动步伐团队，从而物理解耦业务研发团队和根本举动步伐团队。基于利用场景和公司实际技能能力打造一套根本举动步伐支持多措辞开拓。这样，才能在异构的企业系统环境中提高快速迭代、持续交付的能力
（五）做事网格架构（Service Mesh）ok，我们来办理上面微做事架构未办理的问题
定义• 作为根本做事/举动步伐层，用于处理做事间通信
• 云原生运用有着繁芜的做事拓扑交互，做事网格在这些繁芜的通信中实现要求的可靠通报
实践中常日实现为一组轻量级的网络代理，一样平常与运用程序做事支配在一台物理设备上，在通信层面对运用程序透明
• 根本做事/举动步伐下沉为一个独立的做事（sidecar）
• 运用程序和sidecar一样平常支配在一台物理机器上，可以办理运用程序和自身sidecar的通信问题
做事网格架构
优点• 根本做事/举动步伐独立进程、独立升级
• 业务团队专注于业务逻辑本身
• 根据能力可实现一套根本做事/举动步伐可支持多措辞开拓
• 业务团队和根本举动步伐团队物理解耦
这是笔者的第一篇文章，后面会根据小伙伴们的反馈不断优化、改进、定期更新，喜好的小伙伴们记得收藏、点赞加个关注吧~~~~
