Java软件架构师结合实际项目经验总结软件架构的发展进程与原理（重点讲微服务架构怎么来的）

软件架构师结合实际项目经验总结软件架构的发展进程与原理

一、前言

笔者自己一直从事软件开发工作，算上大四实习1年，一直到今年整整12年，这期间有些人已经转了管理岗或者转行，已经完全不敲代码了！笔者依然在一线编码！
笔者做开发是因为出自对计算机的兴趣，不单单是为了谋生！是一种兴趣与爱好！
笔者的我，头发茂密，肌肉发达，发际线良好，并且没有皱纹与白发！我不喜欢穿格子衫，但是确实去哪里都背着电脑！33岁依然青春永在！我的计算机人生才刚刚开始！
这期间前前后后、左左右右接触了大大小小几十个不同行业不同业务实际应用的项目！笔者结合自己的实际项目经验总结一下软件的架构的近10年的发展进程，刚好笔者处于离职状态，正好为进军软件架构师的新的职业旅途做铺垫！

包括微服务架构当前应用很广泛，微服务服务到底是啥？微服务架构是怎么来的？为啥要用springcloud啊？dubbo与springcloud什么区别？
跟着笔者的职业生涯项目递进！

二、软件架构发展的演进

（一）单体架构

A B C D 代表功能模块，都放在一起！
优点：部署方便，开发简单！
缺点：随着功能研发越来越多，启动慢！ 应用部署包越来越大！
可靠性差，功能都写在一起，会互相影响,D模块引起宕机，ABC都受影响！高耦合！
可伸缩性差
扩展性可维护性差
性能低

小型项目应用场景多，比如学校政务的网站系统、企业内部的OA系统、不对外的小型项目！就算宕机了也影响不是很大！

（二）垂直架构

垂直架构是指将单体架构的多个模块拆分为多个独立的项目，形成多个独立的单体的架构！

改进点：启动快一点！
可靠性有所提升
可伸缩性有所提升
扩展性可维护有所性提升
性能有所提升

缺点：重复功能太多，如果大家都需要公用的功能，就比较重复！

E模块重复，多个应用要重复的包含这个模块！比较臃肿！多个应用还得保证E模块的同步性，容易出错！
实际应用场景：银行、政务项目的数据推送共享的子项目经常用到这种架构！功能需求比较独立的项目！与主体项目拆分解耦单独部署！

（三）分布式架构

将垂直架构的重复模块拆分出来，当作独立服务项目，供其他服务的消费者消费，以实现服务的共享与重用！就是分布式架构！
比如：APP1与APP2都需要短信的功能，E就单独做短信的服务功能！APP1需要短信的时候就调用E、同理APP2需要的短信业务的时候也调用E实现！就算垂直架构的改进！

E为短信服务的提供者（生产者）， APP1与APP2为短信服务的消费者！

分布式架构主要解决就算垂直架构的重复功能的短板！

实际应用场景：银行、政务系统的短信服务！企业内部的邮件服务！加密、统一认证服务！公用性的服务单独拆分作为独立服务提供其他服务消费者消费！小型的互联网OA、协同项目！

分布式架构应用场景实际应用场景比较多，并发数、用户量不是特别大的应用系统，公共的服务个数没有那么多，消费者服务也比较固化！

分布式架构存在的缺点：
服务的提供者如果变了地址，所有服务的消费者都要改，跟着调整比较麻烦！
如果这个服务的提供者很多个，这个服务器消费者调用的时候，就很乱！如果有几十个服务提供者，越多，服务的消费者调用就越来越乱，就像是一团乱麻！

这个弊端情况笔者亲自在早期的银行项目中真正感受过这个架构的弊端！比如一笔交易操作，需要调用多个服务的提供者，最终完成一个整体的事务！这个过程就就需要频繁服务消费，整个过程就会很乱，并且服务提供者的地址服务器会经常调整维护，可靠性或者未来的维护成本就比较高！

（四）SOA面向服务架构

概念：

SOA（Service-Oriented Architecture），即面向服务的架构！
SOA 将应用程序的不同功能单元（称为服务）通过定义良好的接口和契约联系起来。每个服务都具有明确的业务功能，可以独立地进行开发、部署、升级和维护。

企业服务总线（ESB）
ESB 是 SOA 架构中的核心组件之一，它充当服务之间的通信中介。
ESB 提供了服务的注册、发现、路由、转换和监控负载均衡，流量控制、加密过滤等功能，使得不同的服务可以方便地进行集成和交互。

笔者通俗的解释：
ESB企业总线是各个服务之间互相调用的中间件代理中介！
ABDCEF项目服务之间会互相调用，分布式架构是直接按服务的生产者与消费者的角色直接物理的调用，SOA架构是服务之间都经过这个ESB中间件来实现调用！
SOA是架构是把每个服务按照服务的提供者、消费者的划分好，并且接口契约已经定好公共化！

比如你想买房，有人卖房，你得通过房产中介去交易，
你是买房服务的消费者，卖房的人是服务的提供者，房产中介就是ESB企业总线！
房源业主的信息都注册在中介公司，你们买房的整个交易都要按照中介的定好的规范来执行，这个规范就是SOA的概念！中介公司有交易规范化的数据，就知道那些客户是优质客户，那些买卖的比较频繁，这就是对应到ESB的服务的注册、发现、路由、转换和监控！对于银行的企业总线就是数据挖掘息息相关！那些交易操作频繁，那些是优质客户，那些存在金融风险！

实际应用场景：
笔者亲自参与某银行的企业总线的构建过程，并且亲自对业务的进行服务治理！
用到IBM 的企业总线 ESB 产品 IIB（IBM Integration Bus）！因为亲自参与研发，对这个SOA架构理解还是比较深刻，因为真正参与做过！现在回看做过的项目，才能领悟核心思想！ESB产品比较重量级！

Dubbo框架也是基于SOA时代的产物！相对springcloud老一点！

（五）微服务架构

微服务架构是SOA架构的升华，微服务架构强调的一个重点是“业务必须彻底的组件化与服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用，这些小应用之间通过服务完成交互和集成！

微服务架构=80%SOA服务架构思想+100% 的组件化架构思想+80%领域建模思想

特点：对比SOA架构升华，比较侧重组件化服务化的维度！拆分更细小，轻量级！

springcloud是微服务时代的产物！SOA架构是上一代时期的产物！

微服务架构在 SOA 架构的基础上有以下几方面的改进：
微服务架构粒度更小，更轻量级！
在 SOA 架构中，服务的粒度通常较大。一个服务可能包含多个业务功能，较为复杂。
而微服务架构将服务粒度进一步细化。每个微服务专注于单一的业务功能，具有高度的内聚性。这样使得系统更加灵活，易于开发、维护和扩展。比如在一个电商系统中，SOA 架构下可能将订单管理、库存管理等多个功能集成在一个较大的服务中；而在微服务架构下，订单服务、库存服务等分别独立为一个个小的微服务，各自只负责特定的业务功能。

总结微服务与SOA架构类似，微服务颗粒感更小，更轻量级！比较新！

某些旧的维护的互联网项目用的是SOA架构（Dubbo框架的）产品，新型互联网高并发高用户量大的用的大多是是springcloud！比较成熟！

三、总结

把近10年软件架构发展进程与笔者自己的软件开发的工作历程一起合并起来讲一下！时代在变化，应用场景就在变化，技术革新迭代就非常快，但是基本的原理思想还是不变的！复杂问题都是多个简单的问题组合而来！
笔者也开启从一个“软件开发者”身份向“软件架构师”新职业征程进军！