当前位置: 网站首页 > 新闻中心 > SEO推广 > 正文
2016/9/9 11:11:59

【杭州SEO优化】一个完整的微服务系统,应该包含哪些功能?

杭州宝三信息技术有限公司行业时讯编辑日期:2016/9/9 11:11:59

  具备什么样的能力才能算是“服务”?这个话题很大,我这里按照自己的片面理解总结一下,所谓服务就一定会区别于系统的功能,服务是一个或者一组相对的较小且独立的功能单元,是用户可以感知的功能最小集,比如:购物车,订单,信用卡结算等都可以作为单个服务独立提供。

  这个理解显然不够深刻,为了进一步理解为什么微服务在近两年业界迅速窜红,理解为什么微服务会被认为是IT软件架构的未来方向,就要理解为什么我们需要微服务?它能给企业带来什么价值。传统企业的IT软件大多都是各种独立系统的堆砌,这些系统的问题总结来说就是扩展性差,可靠性不高,维护成本高。后来有了一个叫SOA的软件架构专门针对这些问题给出了一套解决方案,很多企业也因此将自身IT系统迁移到SOA架构上。但是,由于SOA早期均使用了总线模式,这种总线模式是与某种技术栈强绑定的,比如:J2EE。这导致很多企业的遗留系统很难对接,切换时间太长,成本太高,新系统稳定性的收敛也需要一些时间。最终SOA开起来很美,但却成为了企业级奢侈品,中小公司都望而生畏。

  微服务要从两个方面来理解,一个是“微”,一个是“服务”。体型小到一定程度才能叫“微”,这个程度是什么呢?一个身高1米6,体重90斤的MM,我们说她苗条。微服务也一样,根据亚马逊CEO Bezos给出的有趣定义,单个微服务的设计、开发、测试和运维的所有人加在一起吃饭,只需要两个批萨就够了,这是就是著名的two pizza team rule。

  下面是微服务提供的能力,以及背后需要付出的代价。

  单个微服务代码量小,易修改和维护。但是,系统复杂度的总量是不变的,每个服务代码少了,但服务的个数肯定就多了。就跟拼图游戏一样,切的越碎,越难拼出整幅图。一个系统被拆分成零碎的微服务,最后要集成为一个完整的系统,其复杂度肯定比大块的功能集成要高很多。

  单个微服务数据独立,可独立部署和运行。虽然微服务本身是可以独立部署和运行的,但仍然避免不了业务上的你来我往,这就涉及到要对外通信,当微服务的数量达到一定量级的时候,如何提供一个高效的集群通信机制成为一个问题。

  单个微服务拥有自己的进程,进程本身就可以动态的启停,为无缝升级的打好了基础,但谁来启动和停止进程,什么时机,选择在哪台设备上做这件事情才是无缝升级的关键。这个能力并不是微服务本身提供的,而是需要背后强大的版本管理和部署能力。

  多个相同的微服务可以做负载均衡,提高性能和可靠性。正是因为相同微服务可以有多个不同实例,让服务按需动态伸缩成为可能,在高峰期可以启动更多的相同的微服务实例为更多用户服务,以此提高响应速度。同时这种机制也提供了高可靠性,在某个微服务故障后,其他相同的微服务可以接替其工作,对外表现为某个设备故障后业务不中断。

  同样的道理,微服务本身是不会去关心系统负载的,那么什么时候应该启动更多的微服务,多个微服务的流量应该如何调度和分发,这背后也有一套复杂的负载监控和均衡的系统在起作用。

  微服务可以独立部署和对外提供服务,微服务的业务上线和下线是动态的,当一个新的微服务上线时,用户是如何访问到这种新的服务?这就需要有一个统一的入口,新的服务可以动态的注册到这个入口上,用户每次访问时可以从这个入口拿到系统所有服务的访问地址,类似于到餐厅吃饭,新菜要写到“菜单”中,以供用户选择。这个统一的系统入口并不是微服务本身的一部分,所以这种能力需要系统单独提供。

  还有一些企业级关注的系统问题,比如,安全策略如何集中管理?系统故障