微服务技术的历史和未来发展趋势

技术感言

        “微服务”架构是近期IT领域非常热门的概念。
本人感觉最近几年微服务太火了，大家都在建设微服务，仿佛不谈点微服务相关的技术，都显得不是那么高大尚了。为些很多公司团队都在大刀阔斧的地微服务建设，但很多团队并没有实际微服务踩坑经验，很多团队甚至强行为了微服务而去微服务，最终写成一个大型的分布式单体应用，就是改造后的系统既没有微服务的快速扩容，灵活发布的特性，也让原本的单体应用失去了方便开发，部署容易的特性（项目拆为多份，开发部署复杂度都提高了），不得不说是得不偿失。毕竟200斤的胖子不是一顿饭吃出来的。

技术演变

        今天我们一起探讨一下从最原始的RPC到如今的微服务演变历程。早期计算机应用程序全部是单体应用，而且使用的语言都是汇编，哪时候可没有什么码农，都是高精尖的专家，这一点绝对无可厚非。直到使用C语言的时候在软件领域可就算已经奔小康了，因为高级语言的出现催生出一个新型职业“码农”和“IT民工”等。仔细想想其实我们大可不必因为此等称谓而自悲，“码农”和“IT民工“全部是世界的最忠诚的创造者，总比哪些混吃等死的人强。
        唉！不好意思跑题了，下面我们书归正传。

微服务架构演变

        C/S->B/S-SOA-> MicroService

C/S架构：

        富客户端架构，由于客户端程序承载所有业务逻辑和人机交互界面渲染等所以承担很大的压力，数据方面只是通过与数据库交互来达到持久化数据，以此满足项目软件的所有需求标准。
优点：
1.界面和操作可以很丰富
2.安全性能可以很容易保证，容易实现多层认证
3.只有一层交互，响应速度快
缺点：
1.适用面窄，通常用于局域网
2.用户群固定，安装可用，不适合面向一些不可知的用户
3.维护成本高，发生一次升级所有客户端都需要改变

B/S架构：

        Browser+WebAPP+DBServer端构成三层架构，显示逻辑交给web浏览器，事物处理逻辑放在服务端的WebAPP上，从而减少客户端的压力。B/S架构无需安装，只要有Web浏览器即可。
优点：
1.客户端无需安装，有Web浏览器即可
2.直接放在广域网上，通过一定的权限控制实现多客户访问的目的，交互性强
3.无需升级多个客户端，只要升级服务器即可
4.分布性：可以随时进行查询，浏览等业务
5.业务扩展方便：增加网页即可增加服务器功能
6.维护简单方便：改变网页，即可实现所有用户同步更新
7.开发简单，共享性低，成本低，数据可以持久存储在云端而不必担心数据的丢失。
缺点：
1.在跨浏览器上，B/S架构不尽人意
2.表现要达到CS程序的程度需要花费很大的精力
3.在速度和安全性上要花费巨大的设计成本（最大的问题）
4.客户端与服务器端交互是请求响应，需要经常刷新页面

SOA架构：

        面向服务的软件架构是一种软件设计模式，主要应用于不同应用组件之间通过网络协议来互交操作。从应用层面：SOA是一种应用框架，它着眼于日常的业务应用，并 将它们划分为单独的业务功能和流程，即所谓的服务。从软件层面：SOA是一个组件模型，它将应用程序的不用功能单元（服务）通过这些服务之间定义良好的接口和契约联系起来。
企业级应用，在架构方面比较推荐面向接口开发，采用最典型的5层架构。
View->IService->ServiceImpl->IDao->DaoImpl
        View：
        用户界面层GUI的最终用户或应用程序访问的应用程序界面。.
         IService：
        业务逻辑服务接口层将封装所有业务声明接口，可以通过不同的实现层来应对业务的不断变化。在软件领域应用接口是为了封装业务变化而出现的一门技术。
        ServiceImpl：
        业务逻辑接口实现层为了应对软件需求变化，而采用同一接口标准对应多个具体实现版本，软件可以在不同的应用场景下载入不同的接口实现来应对变化。
         IDao：
        数据持久化接口，软件在日常运行中产生大量的业务数据需要持久化存储，但软件本身并不关心数据存在哪里。所以只声明数据存储接口。
         DaoImpl：
         数据持久化接口实现层，根据软件声明的数据持久化接口，完成数据具体存储数据库、文件、云等。

MicroService架构：

        微服务有效的拆分应用，实现敏捷开发和部署
优点：
1.每个服务相对较小，只关注一个业务功能，开发者易于理解，IDE（集成开发环境）处理效率快，Web容器压力小，容器启动速度快，易于调高劳动生产率和生产环境部署速度
2.每个服务都可以独立部署，简化了部署新服务版本的流程
3.易于规模化开发，多个开发团队可以并行开发，每个团队负责一项服务
4.改善故障隔离，一个服务宕机不会影响其他服务
5.微服务是松散耦合的，每个服务可以进行独立的开发和部署
6.无需长期使用一套技术线，可使用不同的编程语言和工具开发
缺点：
1.运维成本高，几十甚至上百道工序高效运转
2.开发团队需要保证集群可用，保证数据库集群可用，这就意味着团队需要高品质的自动化技术
3.服务波及，服务间通过接口进行联系，微服务架构模式应用个改变将会波及多个服务产生雪崩效应。
4.分布式系统的复杂性，分布式系统意味着开发者需要考虑网络延迟、容错、消息序列化、不可靠的网络、异步、版本控制、负载等。
5.重复劳动，在很多服务中可能都会使用到同一个功能，而这一功能点没有足够大到提供一个服务的程度，这个时候可能不同的服务团队都会单独开发这一功能，重复的业务逻辑，这违背了良好的软件工程中的很多原则。

且行且珍惜

        微服务是很好的技术，但在使用过程中请量力而行，切不可盲目追求大而全最终开发出非常臃肿的服务系统。微服务从诞生之日开始其实一直提倡小而精的设计思想，放眼当下主流技术发展趋势请各位且行且珍惜吧。
        针对当前的微服务技术SpringCloud框架我计划抽时间整理一部完整的教程，对自己是温故而知新，对别人就是抛砖引玉。

下一篇 SpringCloud核心功能

SpringCloud终极教程之核心讲解