类服务架构

前言

这篇文章是在最近阅读了一些开源框架以及一些架构思想后有感整理后写下来的，只是代表我自己的理解和分享，同时也提供给一些同样做技术的朋友们一起看了解技术的变化，为什么要说是类服务呢？因为我不敢保证自己的想法一定就是完整的服务怕板门弄斧，所以只好这样称呼了

平台技术的历史变化

大家都知道，其实软件开发无非就是两个大的方向，一个是应用程序C-S的客户端模型（需要下载APP等安装包），另一个是B-S（基于浏览器访问模型），其实在以前大家一直有偏见，认为B-S浏览器模型是没有客户端模型的技术含量高，其实在我看来无论是B-S还是C-S，这种区分都只是局限于前端展示的区分（所以大家的偏见其实是前端展现技术的偏见），但是一个平台最总要的就是后台服务的提供。
什么是后台服务呢？你使用支付宝的时候你的APP上面有一个余额显示，同样你登录支付宝的Web访问也一样有一个余额显示，而这个余额一般是来自同一个业务处理返回的，所以其实也可以说，Web的前端和APP都使用了这个服务然后提供展示效果。

那么我们的模型其实可以这样展现：

当然这只是其中某一个服务的模式，真正的平台是成千上万个服务的累积起来的，而且服务也不只是提供数据，也有数据流向服务的，比如平台下单等等
现如今是这样的模式，那么以前是怎么样的呢？

以前的软件开发模式：

看的出来和前面的模式比较，这种开发模式是直接访问数据库的，在流程上面的确是简化了，但是同样也遇到了一个问题，就是如果此时项目组来了一个新的项目，而这个新的项目有一个BUG，这个BUG导致数据库有大量的脏数据产生，甚至出现了为授权的数据（比如没有走正常逻辑的数据，比如下单的数据没有支付成功就直接写入数据库了）

为了保证平台的安全性，已经平台的可靠性所以产生了服务治理的概念，什么是服务治理呢？

如图这只是一个普通的手机APP的开发，但是由于提供的服务太多了导致研发过程中特别的混杂，而且如果服务和服务之间有冲突的话，比如你要先使用支付服务支付完款项后，才能使用下单服务，这样在这种情况下会很杂乱，甚至会导致还未支付，结果就下单了，在强壮的平台，这种情况是不允许的

服务治理模式：

如图我们可以看出来我们将全部服务整合成了一个整体，通过一个所谓的服务治理框架去整合，然后对外提供服务（比如使用阿里巴巴的dubbo等等），这样开发人员就可以根据自己需要的场景去处理指定的业务，模块的划分能让平台管理更加完善从而避免服务于服务直接的冲突。
图片中还有一个用于保证安全的中间件，其实它本身也是一个服务云，我们可以通过划分服务云，让相同类型的服务集中在一起

那么服务治理框架有什么用呢？

所以其实像淘宝这种大型平台，真正核心强大支撑业务坚挺的其实就是服务云的强大

服务云和消息队列

其实消息队列我是应该重点讲的，但是因为这篇文章是面向大众化，具有黑盒子效应，所以不方便说的太详细，所以我只好大概概括，大家从上面了解到了服务和服务直接其实都是一个个程序进程，进程直接必然会有通信，消息队列不只是用作解耦，有时候还用来通知进程，当然这里我们就不详细说服务云内部的消息队列的用途，我们来说说服务云和服务云直接的消息队列

如图：

其实你可以这样理解，服务云1当要通知服务云2去做某一个业务的时候，会往消息队列发送一个消息，就好像一封信一样通知服务云2去进行某个业务，通过消息队列可以整合服务云，让服务云直接是一个整体对外提供服务

那么什么是消息队列呢？其实可以把消息队列比作一个邮递员，把消息称为信件的话，那么邮递员的目标就是把这个信递给目标

简单描述整合大数据平台

这里我指定的是storm的流式处理框架，当然还有MapReduce和Spark等等，但是取决于具体情况

结尾

这篇文章是面向大众的本身自己没有打算写的特别详细，只是希望能给大家一个大平台的架构概念，当然人是灵活的技术是死的，不同的组合方法能用出不同的效果，如果大家有疑问可以给我留言