返回 登录
0

专访顾伟:企业如何基于微服务进行开发?

编者按:越来越多的公司开始尝试使用微服务架构(Microservices Architecture)构建围绕业务、细粒度的分布式系统。微服务的优势显而易见,不过在其带来灵活性、扩展性和可伸缩性的同时,也面临着诸多挑战,譬如服务拆分、服务治理、测试、自动化部署以及监控告警等。日前,CSDN记者专访了普元信息主任架构师顾伟,请他分享其使用微服务的实践以及思路。

嘉宾:顾伟,现任普元信息主任架构师。长期致力于IT技术研究、产品设计与开发、架构咨询等工作,擅长Web、OSGI、CI/CD、服务治理、云计算等领域技术。对DevOps、自动化运维、微服务架构有着浓厚的兴趣。

推荐:顾伟将在2016年7月7日的「微服务与容器技术实践沙龙」中,分享《基于微服务架构的技术实践》,主题摘要如下:

  1. 对微服务架构的认识:描述微服务演进过程、常见认知误区等;
  2. 微服务架构实践:阐述结合容器云技术,分享在微服务架构中做的关键设计,使用技术栈,遇到的问题,存在欠缺等;
  3. 微服务展望与总结:应对企业需求,来看微服务的应用前景,对本次分享进行最后总结。

以下为专访正文:

CSDN:请先和大家介绍下您和目前所从事的工作,以及关注哪些技术领域?

顾伟大:大家好,我是普元软件的顾伟,目前担任普元主任架构师一职,负责公司新一代产品的架构设计工作。个人比较关注云计算、自动化运维、容器、微服务、以及传统的插件开发等领域技术。

CSDN:您能谈谈微服务(MicroServices)这个概念的诞生背景吗?

顾伟大:在过去的10多年中,甚至是微服务日趋流行的当下,绝大多数应用采用的仍是我们熟悉的传统架构,称之为“单块架构”模式,这种架构虽然有着包括便于测试、便于部署、便于监控等优势,但不可否认的是其面临着更多的挑战,比如说交付周期长、瓶颈明显等问题,在这么一个大背景下,微服务架构被越来越多的提及。当然虽说有着一堆好处,但其实微服务架构目前还是缺乏很多的实践,每个概念的诞生到最终普及都是需要经过很长的路的。

CSDN:网上有人认为微服务算是一个分水岭,也是传统技术人士倒戈互联网, 以互联网为代表的技术思想确立的里程碑。能否分享下您眼中的微服务,以及您对微服务的认识和理解。

顾伟大:在我的认识里,传统技术和互联网技术并没有本质的区别,只是现在大家对IT数字化要求越来越高,间接的对这些基础能力(比如快速迭代、灰度、漂移)要求越来越高,使得很多人认为互联网技术才是解决问题的途径。我一直对互联网技术的边界理解很模糊,比如MySQL就一定是互联网技术?Oracle就不是?好像不能这么界定吧。

我对微服务的理解是这样的,微服务其实是一个架构风格,包括Martin Flower在提及的时候,只是给了很多建议,但并没有给出严格的规范定义,所以更多的是需要大家基于自己的业务目标去得出最佳实践,而不应该使用一个所谓的业界成熟的微服务平台之类。确切的说,微服务架构给了我们一些很好的设计及经验总结,至于如何运用,是个仁者见仁的事。

CSDN:微服务能够解决我们哪些的难点、挑战和痛点?

顾伟大:刚才上面我提到了微服务只是个架构风格,不是一个万能钥匙,就我们自己的实践来说(我只能说我们是为了解决什么问题),我们主要利用微服务架构解决:

  • 独立灵活部署
  • 容错
  • 扩展
  • 数据分散管理
  • 领域系统拆分

CSDN:与传统单块架构相比,微服务架构有哪些特点?

顾伟大:这块我觉得谁总结的也没有Martin Flower好,我就权当复述一遍吧:

  • 组件与服务
  • 围绕业务功能进行组织
  • 强化终端弱化管道
  • 分散治理
  • 分散数据管理
  • 基础设施自动化
  • 容错设计
  • ……

CSDN:微服务架构是否适用于互联网应用?为什么?

顾伟大:结合微服务架构的特征,我觉得其当然是和互联网应用,而且很多互联网应用早已是这样实践的,因为其带来的好处与互联网应用追求的快速迭代、快速试错试对、业务驱动设计、高可用、易伸缩等能力是完全可以匹配上的。

CSDN:微服务架构是当前互联网业界的一个技术热点,各自公司都有计划开展微服务化体系建设,不过,一个微服务架构有哪些技术关注点?需要哪些基础框架或组件来支持微服务架构?这些框架或组件该如何选型?

这个我只能结合我们的实践来说,我们在基于微服务架构开发时,比较关注的是其性能、延展性、数据一致性、事务等。我们用了很多框架,基础设施层用了openstack、kubernetes、docker、coreos、etcd、flannel、saltstack等,中间服务层用了springboot、hystrix、swagger、jenkins、nexus、gitlab等,前端用了想react、redux等技术。

选型思路上,主要有这么四点:

  • 首先是需求匹配性
  • 接着是团队cover能力
  • 再者成熟度及社区热度
  • 还会看看后台支撑厂商是谁

CSDN:微服务架构下Docker怎么玩?您有什么心得和体会可分享?

**顾伟大:**Docker也火了好些年了,现在很多人喜欢将其和微服务架构放在一起,认为是实现微服务架构的一个很好的技术支撑。从我们的实践来看,docker现在的市场相对还比较乱,比如kubernetes、mesos、docker自身等都在做包括调度、编排等事情,建议大家选择一个方向后不要轻言放弃,要真正的深入使用和实践。当然,现在各家技术的成熟度都还不够,比如网络方案,存储方案都或多或少受限,大家可先从一些应用试点开始,逐步的来使用这块技术,随着社区成熟、自身团队能力的提升,很多问题会慢慢得到好的解决方法。

CSDN:微服务器骤然兴起,企业的接受也需要有过程,在市场开拓等方面,您有如何考虑?

顾伟大:这是个好大的话题,现在的市场营销手段越来越丰富,大家都希望合力培育一个更好的生态,但我觉得还是要从务实开始,比如通过将自身的一些实践开放出来,大家共同来看问题、解决问题,才是一个最好的路线,切勿通过纯市场方式来做,最终受苦的是自己。所以建议大家可以通过更多的分享交流方式(比如沙龙、大会等),把自己实实在在做的事情,遇到的问题说出来,由大家共同来推动技术及市场的前行。

CSDN:您具有丰富的微服务架构实践经验,能否简单介绍一个典型案例?

顾伟大:谈不上丰富,可以说说我们做DevOps的一个平台的过程:

在平台设计之初,领域系统拆分尤为重要(DDD),这些领域系统其实就可以作为一个个微服务来实现,我们大概拆分了20个左右的领域系统(包括发布管理、配置管理、产品管理、市场、项目管理、文档、mock等)。

在实现过程中,边界尤为重要,拿软件配置管理这个微服务来说,它给外部提供的就是配置的能力(结合不同环境的配置的增删改查、配置组、变更轨迹等),所以需要快速定义出API及SPI,让你的上下游服务及团队可以协作干活。

紧接着要考虑的是服务的跨功能需求,比如我作为上游的熔断能力,我作为下游的流控能力,认证方式(当然这些随着积累,可做成通用框架),支持的部署规格等。

总的来说,微服务架构实践时,更多要求的是持续积累的能力,要通过积累自身的基础设施、基础服务、业务服务等,支撑复用;同时对于微服务的安全、监控等也尤为重要(毕竟相对于传统单块架构,这个更复杂了),除了微服务的每个自治性要求,还需要一定的通用运营支撑能力,才能把微服务架构运用的更灵活更有效。

评论