高手问答第 173 期 —— 如何快速稳定落地微服务架构?

局长 发布于 2017/10/17 19:31
阅读 6K+
收藏 52

很久没做过关于微服务的高手问答了,时隔一年,我们再次邀请到了黄勇老师,OSCHINA 本期高手问答(10 月 18 日-10 月 24 日) 将由@黄勇 为大家解答关于微服务架构方面的问题。

黄勇,现任特赞科技 CTO,曾任阿里巴巴公司系统架构师。具有丰富的互联网产品架构经验与技术管理经验,擅长敏捷开发模式,推崇“轻量级”系统架构。国内开源软件推动者之一,活跃于 OSChina 技术社区,Smart 开源框架创始人,畅销书《架构探险》作者,技术大会讲师,企业内训师。热爱技术交流,乐于分享自己的成长经验。

微服务已经三岁了,对于微服务,大家似乎更多是持观望的态度。事实上,微服务是一个灵活的技术架构,它不应绑定在特定的技术平台上,微服务不存在任何的局限性,同时还要确保较强的兼容性。我们应该用最合适的编程语言和开发框架,以最低的成本实现业务目标。

这正是微服务所提倡的 —— 用最合适的技术以最高效的方式来解决实际应用中的问题。

要完全掌握微服务存在一定的技术门槛,但对开发者而言,掌握这样一项技术是十分有意义的,相信大家对于微服务会有不少的问题,那么不妨带着问题进入到本期的高手问答。

本期问答内容:

  1. 使用微服务的关键技术点
  2. 微服务的使用相关案例分享
  3. 什么时候考虑采用微服务架构?
  4. 如何快速稳定落地微服务架构?
  5. Spring Boot + Spring Cloud 就是微服务吗?

或有其他关于微服务的问题,也欢迎大家积极提问!

为了鼓励踊跃提问,@黄勇 会在问答结束后从提问者中抽取 5 名幸运会员赠予《轻量级微服务架构(下册)》一书。

购买链接:https://item.jd.com/12164789.html

OSChina 高手问答一贯的风格,不欢迎任何与主题无关的讨论和喷子。
下面欢迎大家就微服务方面的问题向@黄勇 提问,请直接回帖提问。

>>>上期高手问答:https://www.oschina.net/question/2720166_2201257

加载中
0
局长
局长

高手问答第 173 期 —— 如何快速稳定落地微服务架构?

@POTUS @chaun @myw31415926 @跳蚤 @T_T_J

恭喜以上五位由黄勇老师挑选的用户获得《轻量级微服务架构(下册)》图书一本

请尽快私信@局长告知快递信息(格式:姓名+电话+地址),感谢支持~

3
iamcoder
iamcoder

@黄勇 前段时间研究微服务,学习了spring boot, spring cloud,微服务架构与实践相关分享和书物,苦于没有线上系统的实践经验和指导,这本书涵盖了测试,服务监控,运维等落地方案,真乃久旱甘霖,使人如沐春风!

黄勇
黄勇
这段评价,已作为精彩书评 :)
2
赤脚小子
赤脚小子

@黄勇

我的天呐竟然是您!!我买了您所有的书,都是正版!(除了最新这本,在购物车等双十一呢),非常喜欢您的书,非常开心能在这里跟您交流,从您的《从零开始写WEB框架》开始关注您的,最近我也一直在看微服务相关的书,也在公司的项目中进行了部分实践,最近spring mesh的概念很火,istio也在发力,请问您对二者看法如何?真的是微服务的未来会取代spring cloud呢?

再次表示非常开心能跟您交流哈哈哈哈真心希望有机会能跟您在某次技术大会现场见面,签名合影留念!!!期待啊!!!

黄勇
黄勇
没错,是我,我一直都在 :)
2
只身打马过草地
只身打马过草地

@黄勇 您好 , 有两个问题请教一下:

1. 针对现有的系统如何进行服务化改造,有什么比较好的方式

2. 在服务拆分之后,服务方法的权限应该要怎么控制,针对不同的调用者和不同的控制粒度

黄勇
黄勇
1. 服务化改造是一个长期的过程,建议先根据业务进行服务切分,然后分阶段实施。 2. 服务的 API 权限可在服务网关上进行统一控制。
2
mahengyang
mahengyang

@黄勇 微服务是不是对运维的要求非常高?老系统平滑的迁移到微服务,有真实案例可以借鉴吗?

黄勇
黄勇
没错,微服务需要较强的运维能力,而且不是传统的“纯运维”,而是“开发运维/DevOps”。 我们两年前就开始对老系统进行微服务改造,目前所有的业务都在这套微服务架构下运行。
2
l
lvzi98

@黄勇 微服务会增大维护人员的工作? 之前我们公司把比较重的老系统拆分成微服务时基本是重做一套新的系统,新老系统并行一段时间,然后把老系统废弃,请问这种拆分工作有经验介绍下子么

黄勇
黄勇
1. 不是微服务增大了运维人员工作,而是微服务改变了运维人员的工作方式,甚至提升了运维人员的价值。 2. 我们两年前就开始对老系统进行微服务改造,至今我们所有的业务都跑在微服务架构上了,踩了很多坑,也尝了不少甜头,因此我才想写这本书。
2
跳蚤
跳蚤

@黄勇

目前我们使用dubbo做服务,遇到的问题:

1. 由于dubbo没有springcloud体系下的服务网关,我们都是在用户终端(浏览器、手机等)调用一个web后台,通过web后台来提供类似facade的功能来集成后面的各种服务,这种模式您有什么看法?或者有没有更好的建议?

2. 用户鉴权这块,我理解的一般的微服务架构,应该是由服务网关来做用户鉴权,比如校验header里token之类的,比如使用openresty用lua连redis来校验token或JWT等。而由于我们服务使用dubbo提供,在dubbo之前还有一个web应用,web应用目前使用的传统的session和JWT相结合的方式。不知道您有没有更好的推荐的方式

3. 微服务后,数据一致性的问题必然会出现。目前我们暂时没有做到分布式事务,一般都是关键数据先入库,通过定时任务读库重试,后台在来一个处理状态的查询。这样的问题您怎么看

4. 链路跟踪,目前在研究PinPoint,能对服务的调用情况做一些统计分析和监控,但是部署好后感觉好像没有这个系统一样,因为部署好后经常忘记上去看看,好像不存在这个系统一样。不出问题就不会去关注。不知道是不是关注点或使用习惯上理解有偏差,我们往往忽视这个系统,感觉作用不太大

黄勇
黄勇
回复 @跳蚤 : 1. 服务之间的调用一般可用 RPC 进行通信,此时无需服务网管,直接在客户端进行服务发现即可。 2. 不一定要用 HTTP,但最好协议上能统一,这样服务网关处理起来比较容易。
跳蚤
跳蚤
回复 @黄勇 : 关于服务网关,我也有几个问题想请教下: 1、服务发现也通过服务网关来做么?如果通过服务网关来做,我们服务是dubbo实现的,那么服务网关就要去读取zk的注册信息来获取服务提供方,是这样么? 2、当一个请求到达服务网关后,服务网关调用后台服务,那么我的服务是否一定要用rest方式提供;目前我们使用dubbo协议,底层也就是netty来调用的
黄勇
黄勇
3. 分布式事务一致性建议做到数据的最终一致性即可,我们结合了 Event-Sourcing 与 MQ 技术,实现了一款轻量级的分布式事务框架,书中也有介绍。 4. 链路追踪系统必须要有,而且它也是微服务基础设施之一,缺少它将不利于排错,从而导致解决问题的效率变慢,建议根据案例给大家做一些培训,从而在团队内部进行推广。
黄勇
黄勇
1. 微服务架构中需要有服务网关的概念,它不仅用来屏蔽一些调用细节,而且还用于服务发现与安全控制等细节。这方面我推荐根据自建,我们用 Node.js 开发了自己的服务网关,效果非常不错。 2. 用户鉴权是服务网关的职责之一,我们的方案是通过 Redis 来存储登录成功后生成的 Token 信息,每次请求时都去判断这个 Token 是否有效。
2
p2ng
p2ng

@黄勇

最近团队也在考虑微服务架构落地问题,背景是2B业务系统,日UV上百

1. 由PlayFramework迁移至SpringBoot成本大,价值低,效果差...(换技术框架为了能快速使用已用的组件,社区活跃度高)

2. 梳理独立业务,抽取为服务。对外提供RPC或Http服务

感觉本身业务形态决定了,系统架构,不知道老师会有什么想法呢。

黄勇
黄勇
业务决定架构我觉得是必然的,因为架构本就应该服务于业务,并从业务中体现自己的价值。
黄勇
黄勇
1. 为什么要换框架?Play 挺好的,它同样拥有 Spring 所提供的功能。微服务架构下,咱们不要拘泥在具体的技术框架上,因为不管用哪款框架开发,在微服务世界中,只要它对外的接口调用形式是一致的即可,这些服务都需要进行注册与发现。 2. 建议对外提供 HTTP,并非对客户端,而是对服务网关,此外,服务之间调用可以走 RPC。
2
王桥修道院副院长
王桥修道院副院长

@黄勇 你好!几年前买了《从零开始写web框架》算是对web框架理解的启蒙书吧,没想到几年时间,我们在微服务这里又遇见了。我的问题是:

1.微服务和一般的分布式架构的本质区别到底是在什么地方?微服务架构必然是分布式架构?

2.之前我做过一些调查和实践开发,在公司内部推广时介绍了一些spring cloud和docker的使用,但是大家并没感觉这个架构能带来多少便利,反而增加了工作量(我们是几十人的小公司,做一些微信以及管理平台的业务开发。项目都没前后分离,前端,运维都不专业)。这样的外部条件是不是根本不可能推动微服务?

3.一般来说,微服务是不是更适用于业务快速变化迭代的互联网公司的项目,而不是业务类型基本固定的传统公司项目? 问题有点多,感恩!!

黄勇
黄勇
1. 微服务是一种分布式架构,这一点毋庸置疑,然而微服务架构包含了两个阶段,一是部署阶段,二是运行阶段,不同阶段所关注的内容也不同。详细内容请见本书下册第一章。 2. 如果运维能力有限,那么实施微服务时将会受到一定的压力,会遗漏一些关键的因素,所以我才花了一年时间写完了下册,希望能对运维能力暂时不太强的团队提供帮助。 3. 对于业务较为固定的企业,产品发布频率较低,微服务所带来的价值就不会太明显。
2
黄洪清
黄洪清

@黄勇
微服务中分布式的用户认证和权限管理,是个关键。
最近正好研究这个问题,可参考:https://my.oschina.net/u/3532467/blog/1554174

黄勇
黄勇
赞!安全控制这块,其实是个无底洞,就像性能优化一样,永远没有尽头,我们需要做到的是投入和产出成正比。
当前问题已关闭评论
返回顶部
顶部