转发时请注明原创作者及地址,否则追究责任。原创: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)如果没有自动化部署工具,微服务部署变得一场复杂。
可以关注本人的公众号,多年经验的原创文章共享给大家。