01.鸟瞰架构历史
单体应用:原始氏族时代,氏族内部有简单分工,氏族之间没有联系.
分布式架构:封建社会,每个家庭自给自足,家庭之间有少量交换关系.
SOA架构:前工业时代,企业提供各种成品服务,我为人人,人人为我,相互依赖.
微服务架构:后工业时代,有些企业聚焦提供水电煤等基础设施服务,其他企业在之上提供生活服务,依赖有层次.
02.单体架构
系统只有一个应用,相应地,代码放在一个工程里管理;打包成一个应用;部署在一台机器;在一个DB里存储数据.
单体式应用采用分层架构,按照调用顺序,从上到下一般为表示层,业务层,数据访问层,DB层.
优点：
现有IDE都是集成开发环境,非常适合单体式应用,开发,编译,调试一站式搞定.
一个应用包含所有功能,容易测试和部署.运行在一个物理节点,环境单一,运行稳定,故障恢复简单.
缺点：
业务边界模糊,模块职责不清晰,当系统逐渐变大,代码依赖复杂,难以维护.所有人同时在一个工程上开发,容易发生代码修改冲突,依赖复杂导致项目协调困难,并且局部修改影响不可知,需要全覆盖测试,需要重新部署,难以支持大团队并行开发.
当系统很大时,编译和部署耗时.应用水平扩展难,一方面状态在应用内部管理,无法透明路由;另一方面,不同模块对资源需求差异大,当业务量增大时,一视同仁地为所有模块增加机器导致硬件浪费.
03.分布式架构
在分布式应用架构中,应用相互独立,每个应用代码独立开发,独立部署,应用通过有限的API接口互相关联.
API接口属于应用一部分,一般和表示层处于同一层次,两者共享业务逻辑层.
API和表示层采用同样的web端技术,通讯协议一般使用HTTP,数据格式是JSON,应用集成方式比较简化.
优点：
分布式架构每个应用内部高内聚,独立开发,测试和部署,支持开发敏捷,
应用之间松耦合,业务边界清晰,业务依赖明确,支持大项目并行开发,实现业务敏捷.
缺点：
在分布式架构中,应用的表示层和API没有物理分离,需要同时满足自身业务需求和关联业务需求,相互影响,比如API接口会随着外部应用的需求经常变化,这会导致整个应用重新部署.
运行时,API以HTTP/REST方式通过网络对外提供接口,其通信可靠性和数据的封装性相对于进程内调用比较差,如果没有一些可靠的技术机制,如路由保障/失败重试/监控等,裸奔的API方式将严重影响系统整体可用性.
04.SOA架构
SOA架构提供配套的服务治理,包括服务注册,服务路由,服务授权,服务降级,服务监控等等.这些功能通过专门的中间件ESB支持.SOA架构在分布式垂直切分,把原来单体应用的业务逻辑层独立成service,做到物理上的彻底分离.
优点:
每个service都是浓缩的精华,聚焦某方面核心业务,同时以复用的方式供整个系统共享.
服务作为独立的应用,独立部署,接口清晰,很容易做自动化测试和部署.
服务是无状态的,很容易做水平扩展;通过容器虚拟化技术,实现故障隔离和资源高效利用,业务量大的时候,加机器即可.
基于SOA的系统可以根据服务运行情况,灵活调控服务资源,包括服务上下架,服务升降级等,使系统真正具备可运营的能力.
缺点：
系统依赖复杂,给开发/测试/部署带来一系列挑战.
端到端的调用链路长,可靠性降低,依赖网络状况,服务框架及具体service的质量.
分布式数据一致性和分布式事务支持困难,一般通过最终一致性简化解决.
端到端的测试和排障复杂,SOA对运维提出更高要求.
05.微服务架构
微服务是把一个大型复杂软件应用由一个或多个微服务组成.系统中的各个微服务可被独立部署,各个微服务之间是松耦合的.每个微服务仅关注于完成一件任务并很好地完成该任务.在所有情况下,每个任务代表着一个小的业务能力.
优点：
很好支撑敏捷开发,小团队单独开发,单独部署.
微服务易于被一个开发人员理解,修改和维护.
微服务利于技术重构,允许快速融合最新技术.
微服务是松耦合的,是有功能意义的服务,无论是在开发阶段或部署阶段都是独立的.
微服务能使用不同的语言开发.
缺点：
分布式复杂性.
数据一致性.(各个服务的团队,数据也是分散式治理,会出现不一致的问题)
运维复杂性.
测试复杂性.
06.云原生架构
从技术的角度出发,云原生架构是基于云原生技术的一组架构原则和设计模式的集合,
旨在帮助企业和开发人员充分利用云平台所提供的平台化能力和弹性资源能力.
从云原生架构中,我们可以知晓,将所有的非功能性业务需求,将其转化为基础设施层,而不是由研发人员来处理.同时对于运维人员来说,如果以前负责业务运维的同时,还需要基础架构的运维,此时将非功能性业务下车后,他们只需要负责业务运维就好.
云原生技术是支撑微服务架构的基础设施架构.
22-06-18