zoukankan      html  css  js  c++  java
  • 用普通话说微服务系列(一) 单体应用到微服务的进化

       转发时请注明原创作者及地址,否则追究责任。原创:alunchen

    从工作体验切入

    开始部署应用             

          在很久很久以前,开发与部署web应用时,一开始都是很开心地写完‘整个’应用,以包或者文件夹等方式部署到服务器上。在java中,用war包部署到tomcat服务器;在.net中,在IIS管理器中指定文件夹。应用就这样愉快地运行着。

    噩梦开始前兆             

          突然,开发的应用是一个有市场潜力的应用,或者客户想开发2期,3期...... 这样,应用越变越大、项目上线了、修改bug变得越来越吃力、以前开发此功能的同事走了,修改bug用添加代码的方式修改、项目启动越来越慢。

          就这样,项目支撑了几年...

    噩梦开始前的准备    

          技术负责人突然发现,项目支撑不了多长时间了。并且有其它项目可用到我们开发的功能组件,例如图片处理功能。

          技术负责人很负责地把应用拆分。分成不同的服务开发的形式。例如我们开发的是一个商城平台。技术负责人把商城平台拆分成:图片处理服务、交易服务、用户管理服务、商城数据服务(包括商品、类别等)。这时候,系统开发者们很骄傲地看到此应用拆分成的服务可以跑很多年。

    架构的追求               

          商城拆分的服务跑得很完美,但是随着服务的添加与拆分,架构师看到了重复的工作与服务存在不合理的架构。

          什么样的重复工作呢?当添加一个服务时,手动添加VM来部署、前端又要添加请求新域名IP的服务。

          并且不合理的架构:1)多个服务使用同一个数据库,可能导致数据库压力过大。2)服务的粒度区分不明显,有大有小。3)服务没有同一的认证中心。4)服务动态修改实例数很麻烦。

          针对上面所有的问题,微服务设计思想,就提出了。

    微服务开播啦!

          什么是微服务?微服务是一种架构设计,集合了多个概念而成。因为微服务要运行在分布式环境,提倡自动化,所以微服务有很多专业的实现名词。包括服务发现、熔断限流、服务网格、API网关等。这些个名词,都会用普通话来开篇叙说。

          微服务可以单独跑在一个VM或者Docker上。并且有自己的专门数据库。这个很好理解,微服务提倡解耦。每个微服务可以连接自己的数据库,并且此数据库是独立存在于其它微服务。其它微服务想要访问数据的时候,可以访问我微服务的API即可。

    微服务-服务与数据库独立

    微服务可以编写自己的编程语言。甚至于,在同‘一堆’微服务里,商品微服务用C#、用户微服务用Java、购物车微服务用PHP。多么的‘解耦’啊!

    微服务-服务与开发语言独立

          微服务的粒度提倡不要太少。有人说,微服务的粒度控制在10个类以内,每个类100行代码以内。我的天!这个按代码区分的微服务粒度也太低了!反而引起服务的过度调用。如果平时你要下单购买一个商品时的流程,只需要访问订单、商品、支付微服务。但是你区分的太少,可能访问的微服务变成了十几个,甚至上百。这样想一下性能也太低了吧!因为每个微服务运行在单独的进程里。

    告诫                  

          在选择使用微服务前,需要考虑团队是否有相应的技术。开发微服务需要的技术人员技术相应较高,并且需要理解微服务的一些基本原理,除非公司已经有了一套完整的微服务框架,开发人员只需要在上面像单体应用地开发。

          微服务开发前期需要的周期会相应的增加,甚至是增加几倍。

          微服务需要有相应程序的运维团队去运维你的微服务。如果公司有自己的运维一体化工具,则省去了这个建队需求。

          所以,在使用微服务前,考虑周到,不要盲目地追求使用。最后你可能项目延期、性能比单体应用还慢!

    期待                    

          微服务,还有一段很长的路要走。就在今年2018,微服务提出了2.0版本,服务网格。期待微服务整个体系慢慢完善统一起来。

    微服务的好处

    1)数据源隔离,达到解耦的目的。每个微服务有自己的数据源,如果需要迁移微服务、加大微服务实例数都非常简单,不用再考虑数据切分的事情了。

    2)统一的认证中心、服务发现、服务网关。统一了分布式开发的工具、设计思想。

    3)系统越大,相应地开发周期不会线性的增长。

    微服务的劣处

    1)微服务是分布式开发,所以开发变得异常复杂。分布式系统存在着两大难题,一个是分布式事务,另外一个是分布式锁。

    2)微服务粒度越细,性能越低。

    3)如果没有自动化部署工具,微服务部署变得一场复杂。

    可以关注本人的公众号,多年经验的原创文章共享给大家。

  • 相关阅读:
    Windows SDK编程(Delphi版) 之 应用基础,楔子
    一个小问题引发的论证思考
    Delphi 组件开发教程指南(7)继续模拟动画显示控件
    用PyInstaller将python转成可执行文件exe笔记
    使用 .Net Memory Profiler 诊断 .NET 应用内存泄漏(方法与实践)
    Microsof Office SharePoint 2007 工作流开发环境搭建
    How to monitor Web server performance by using counter logs in System Monitor in IIS
    LINQ之Order By
    window 性能监视器
    内存泄露检测工具
  • 原文地址:https://www.cnblogs.com/alunchen/p/9984160.html
Copyright © 2011-2022 走看看