码迷,mamicode.com
首页 > 其他好文 > 详细

微服务开发攻略之浅析微服务架构

时间:2018-11-07 20:14:03      阅读:157      评论:0      收藏:0      [点我收藏+]

标签:移动   type   内容   最大   proc   浅析   概念   技术分享   就会   

微服务开发攻略之浅析微服务架构

最近这些年,微服务非常火,那你有没想过微服务的动机是什么?其实,最重要的动机就是业务变化太快了。特别是移动互联网出现以后,各种各样的业务:共享单车、支付宝、微信支付等等,业务经历着飞速的变革与创新,所以就要求底层的应用技术能够支撑得上业务的快速变化。
我们看一下应用架构的变迁,其实也是从另一个角度来印证上文说的“快”。
技术分享图片

第一代是单体架构,当然它有很多,例如紧耦合、封闭架构等各种各样的问题。第二代是SOA架构,可能大型企业级的应用里面会比较多,提供了很多种支持,实际上我们看到SOA架构的时候,它已经强调松耦合了。那么他强调这一点是为了什么?其中一点就是因为快(当然不是仅仅为了快)。到现在第三代微服务架构,它实际上是变得更加灵活了。在业务变化非常快速的背景之下,微服务架构是一个非常好的解决方案,微服务的核心——敏捷、灵活、精准弹性。微服务架构出现的最大的意义是不断地提高交付效率,缩短交付周期。
微服务最有名的人——Martin Fowler,在2015年提出了微服务的概念(实际上2009年Netflix就已经开始实践微服务了,但是当时没有微服务一词)。2015年Martin Fowler明确的提出了微服务的概念并对它进行了一些比较清晰的定义,最主要的就是:小、独、轻、松。就是说微服务要小,模块边界要更清晰,支持独立部署独立演进,每个微服务都应该可以独立部署,独立演进,独立升级的。另外允许技术多样性,就是在微服务构成的一个整体的应用系统里面,每一块的业务要用你最适合的技术去实现,而不是都统一用一种语言去实现,这也是微服务非常重要的一个特点。
所有事情都有两面性,那微服务也不是只有好处没有坏处的,它也会带来问题。其实很明显,例如,从运维人员的角度来看,原来只需要运维一个应用;把它拆开后,就需要运维多个应用,复杂性和难度一定是增加的。从开发人员的角度来看,原来写程序的时候,单体应用,方法之间的调用就可以解决很多业务的处理了;变成分布式以后,就要远程调用,不能用简单的进程内的调用了。用远程调用它就会出现一些问题,比如会变慢、可靠性比进程内部的差等等。那开发人员就要去处理这些问题,要去为这些问题做准备。还有一点也是非常重要的,就是数据一致性的问题。原来在单体应用里面,可以用数据库保持数据的一致性(或者说用数据库的事务去保证数据的一致性);但是到分布式系统以后,突然发现这种方式不行了。因为在微服务架构里面提倡的是数据分开,就是说每一个微服务都会有自己独立的数据库。Martin Fowler也讲了允许技术的多样性,到数据这一层也要用最合适的数据库技术去构建单独的微服务。原来保证数据一致性都是关系型数据库,直接用事物就好了。但是到了微服务就不一样,可能有些微服务用的是关系型数据库,但有些微服务用的是非关系型的数据库。所以在这样的前提下,去保证整个系统的数据一致性,也是带来了很大的挑战的。
以上大致介绍了什么是微服务架构,它有什么样的特点,又有什么样的优势和挑战。想了解更多微服务相关内容吗,华为云学院(https://edu.huaweicloud.com/
已上线多门微服务相关课程,从基础知识入门,到开发第一个微服务,到微服务的上线、治理,带你一站式攻克微服务,敏捷开发微服务应用,快来报名学习吧。

微服务开发攻略之浅析微服务架构

标签:移动   type   内容   最大   proc   浅析   概念   技术分享   就会   

原文地址:http://blog.51cto.com/14042634/2314053

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!