微服务技术的历史和未来发展趋势
技术感⾔
“微服务”架构是近期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框架我计划抽时间整理⼀部完整的教程，对⾃⼰是温故⽽知新，对别⼈就是抛砖引⽟。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。