微服务实践中需要注意什么？
极客时间编辑部
讲述：丁婵大小：7.05M时长：05:08
你好，欢迎收听极客视点。
架构的演进基本上是按照最早的单体服务架构开始，将所有的功能模块打包到一起。再到后来的微服务架构，就是将复杂臃肿的单体应用进行细粒度的服务拆分，每个微服务可以交给小的团队进行开发和维护，拆分出来的服务各自独立打包部署。
对于经历过整个架构演进过程的技术专家们来说，他们在微服务实践中总结了哪些经验？InfoQ 编辑薛梁在此前的一次 ArchSummit 全球架构师峰会上，就上述问题邀请了业界几位技术专家共同探讨。以下是重点内容。
什时候拆？怎么拆？拆多细？
在实际工作中，很多技术人都会产生这样的疑问：什么情况下单体要拆微服务，有没有一步到位的办法，传统的应用到底怎么拆，拆多细，如何去衡量？
对于什么时候应该考虑微服务，同程艺龙交通首席架构师李智慧认为，如果要做一个创业公司，做一个新的应用，建议刚开始的时候就设计微服务架构。因为服务本来就是隔离的，可以强制你去独立思考业务模块，逼迫你每天去思考：服务之间的关系是什么？应用之间如何用服务进行组合？这样的思考有助于架构设计，模块之间的关系会更清晰。
阿里巴巴资深技术专家雷卷认为，如果只是做 ERP、CRM 或者 OA，就是一个单机的应用，部署到客户环境，客户每天的访问量不大，单机又没有成为瓶颈；或者对于小型创业公司，刚开始做第一个应用，那就没必要做微服务。
另外从技术层面上讲，比如用 HBase 在设计的时候，对事务一致性要求极致，若拆成微服务，就会有网络延迟之类的问题。关于部署问题，如果客户还没有做容器化、虚拟化，通常也不建议采用微服务。
如果你确定采用微服务架构，就需要考虑拆分到多小，按什么力度来拆分。有很多方法论值得参考，例如 DDD 方法论，它会告诉你如何识别业务系统，如何拆分微服务，怎样做通讯等等。
对于微服务中的成本问题，例如业务试错成本，Shopee 高级首席工程师冯湧认为，可以先验证一下商业模式，在这种情况下，把一个服务拆的太细并不是明智的选择。
其次是要考虑建设成本。微服务可以理解为一艘航空母舰，它周边是有很多舰艇组成战斗群。它需要很多的能力支撑，包括服务治理、运维上线、质量保障等等。如果现在还是小团队、小业务，安心做业务就好。
微服务实践中需要注意哪些坑？
雷卷发现，从原来单一进程改为跨进程分布式调用会出现很多问题，比如 Transaction 事务没法控制，之前设计的 API 会失效。
雷卷举了个例子。之前淘宝店铺里卖家都会装修店铺，装修了十几个页面，在节日的时候一次性发布，这些大促时间比较长，有可能在某一个环节就会出现问题。比如远程调 API 的时候出现一次失败，且没有分布式的事务来控制，就比较麻烦。
所以在拆成微服务之后，远程网络确实是一个很大的问题，同时对接口的设计也有很大的挑战。因为在一些关键性事务上，不能按照 Rest API 来做设计，要提供更面向业务性、原则性的 API 暴露给外部调用。解决的办法是把 API 各种页面状态更改之后归拢形成一个原子化，增加一个幂等性判断，以确保最终的事务一致性。
冯湧更关注服务治理，他认为当公司越来越大的时候，服务内容的治理，比服务本身健康度治理更重要。
例如研发团队上千人的公司，每个团队负责一个业务方向，并且都以微服务的方式来进行相关的系统能力建设。一旦遇到公司级促销活动，对于类似于“对账、营销”等底层技术能力的时候，会很疑惑这么多五花八门的技术，到底该用哪个？
所以，冯湧建议，在未来做规划架构、架构治理工作的人，要更加关注技术上如何合并，哪些适合微服务体系，哪些适合底层基础建设体系，防患于未然。同时在做服务拆分的时候，服务定义要明确：业务职责、业务场景，避免给服务治理风暴留下潜在风险。
以上就是今天的内容，希望对你有所帮助。
原文链接：微服务带来的心理阴影
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(2)
- 最新
- 精选
aoe很多创业公司都倒在了微服务上，后台开发5人左右，还要上微服务，开发、硬件、运维成本都上去了。前期每天几百的访问量，单机应用都毫无压力。好比海面上出现了几搜敌方侦查艇，我方派出了整个航母战斗群应战。2
小斧在未来做规划架构、架构治理工作的人，要更加关注技术上如何合并，哪些适合微服务体系，哪些适合底层基础建设体系，防患于未然。同时在做服务拆分的时候，服务定义要明确：业务职责、业务场景，避免给服务治理风暴留下潜在风险。
收起评论