分布式思想,SOA及其实现
今天我发博客内容为分布式思想,SOA及其实现
毕竟就之前而言,由于我们的能力并不是很足够,所写的程序大部分为单体程序~
(~~没错,将一堆混杂着bug和性能问题且功能不同的代码莫名其妙的拼凑成一个单一线程的程序就是我们做的事情(～￣▽￣)～~~)
虽然有部分横向分层,
(~~像数据库层->dao层->biz层->controller层->web层这种基础玩意我都不好意思叫分层~~)
但是嘛在处理复杂的项目之时还是远远不够的,特别是在现在的实际生产环境下,问题可大了去了:
1. 可伸缩性差:无法根据访问频率部署对应功能等等
(ps:这一大堆杂七杂八的代码混在一堆,简直是高耦合低内聚...怎么可能做到良好的伸缩性~)
2. 项目规模一旦过大,将会造成打包发布时间的大大增加
(ps:编译器:???)
3. 系统错误隔离性差:系统过于高耦合,容易发生一个功能出现问题,整个项目全部GG的情况
(bug小能手落星:教练,这个我熟(≧∇≦)ﾉ)
4. 不同项目的功能模块可能出现重复建设的问题,造成浪费~
在各种莫名其妙问题的加持下,一些程序猿不忍了~在这种情况下,分布式架构横空出世~~
- 分布式架构:对一个复杂业务系统进行垂直分层~使得每一个垂直应用都是一个独立的子系统,应用系统由它们共同组成~
基此,这些子系统就可以部署在不同服务器上,这些服务器还可以位于不同的地域.
(ps:怪不得现在流行模块化开发,这玩意简直是屎山救星好吧,果然是科技解放思想?)
这就是分布式架构~
但是其并不是完全没有副作用来着:
随着分布式应用之间的调用越来越多,整个系统复杂度也会随之急剧上升~
这又导致了SOA的横空出世!
- SOA(Service-Oriented Architecture):面向服务的架构,是一种软件开发模式,允许不同的服务通过服务接口进行可重用和互操作的组合,形成应用程序.它是一种粗粒度,松耦合服务架构,服务之间通过简单,精度定义接口进行通讯,且不涉及底层编程接口和通讯模型~
这种思想所描述的标准可以让急剧差异性的进程通过接口互相联结,
(神圣的接口将我们联系在一起.jpg)
让不同厂商,不同语言的服务能够如同单体程序不同模块一般联结~
这种通信的协议就叫做ESB服务总线(毕竟SOA只是一种架构设计模式来着~)
[ESB服务总线]
常见的SOA实现有三种:
- 基于http+xml的WEB service(SOAP)
- 基于http+json(REST)
- 基于Socket+文本(dubbo)
WEB Service多用于异构系统之间的数据交互,
其传送使用XML,SOAP可以使用XML调用远程方法,便于交互,
再加上一个WSDL描述语言来阐述一下函数、返回值、参数等等...
看上去很美好,不过我看了眼这SOAP请求和响应的实现就感觉美好不起来了...
[SOAP某请求和响应示例]
落星感觉让落星用这玩意实现SOA他得猝死在电脑旁来着...怪不得这玩意只在早期用的比较多来着...
生无可恋时,看了眼基于http+json的实现才好点...
(spring cloud,微服务思想的践行者,预计也会是之后学习的重点?)
[基于http+json的实现]
(没有对比就没有伤害,阳间,真tm阳间)
基于Socket+文本的实现与基于http+json的实现初略看上去区别并不是特别大,
我个人看法是这种实现性能应该会比http+json略强点?
(说人话就是性能好,适合高并发场景)
只是初略看上去的话最大的不同是多了一个自定义协议和一个编解码器?
[基于Socket+文本的实现]
总体而言,soa的实现~~千奇百怪~~各有特色,
像http+json实现方法就遵循RESTful风格,易于使用和理解.
而Scoket+文本实现就更适用高并发、实时性较高的应用场景.
至于http+xml?
虽然我知道其在跨平台等场景下表现良好,but...
**这玩意太费程序猿了!别的实现要精力,这种实现要命啊...**
后记
这是落星本人第一次写相关技术博客来着~总感觉比想象的多花的时间非常多?
毕竟本人纯小白,既无对源码深邃的理解,也无多年的编程经验,甚至刚刚接触这些东西...
不过,效果还是很显著滴,最起码写完博客,我对分布式思想和SOA有了初步的理解~
之后,我会尽量提高博客质量,以求得大家更好的阅读体验(~~话说我这菜鸟博客真的有人读吗...~~)