36 | 微服务架构最佳实践 - 基础设施篇
该思维导图由 AI 生成，仅供参考
自动化测试
自动化部署
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文介绍了微服务架构中的基础设施，包括自动化测试、自动化部署、配置中心、接口框架、API网关、服务发现、服务路由和服务容错等关键基础设施。这些基础设施的作用在于解决微服务架构中面临的挑战，如接口数量增加、部署频率提升、配置管理复杂、外部系统访问困难等问题。文章还介绍了服务监控、服务跟踪和服务安全等相关内容。服务监控能够实时搜集信息并进行分析，避免故障后再来分析，减少了处理时间；服务跟踪则能够跟踪某一个请求在微服务中的完整路径；而服务安全则需要设计服务安全机制来保证业务和数据的安全性。最后，文章提出了一个思考题，即由10位Java高级软件工程师组成的开发团队，采用自研的方式，完成所有的微服务基础设施开发，需要多长时间以及理由。整体而言，本文为读者提供了对微服务架构基础设施的全面了解，有助于他们在实践中更好地应用微服务架构。
《从 0 开始学架构》，新⼈⾸单¥68
全部留言(63)
- 最新
- 精选
孙振超文章中一共列了11个部分，但只有10个人，很明显是不可能是同时开工的，即使能够同时开工也是需要经过几轮迭代才能达到一个比较完善的状态。 依据简单原则和演化原则以及“三个火枪手”的人员分配原则，首先可以做API 网关、配置中心、服务发现、服务路由这4部分，经过一个月的开发+半个月的联调的先让基础框架搭建起来，业务能够运行起来。 业务上线后，为了保证用户体验和问题跟踪，在保留一两个留守同学的情况下，开始服务容错、服务监控、服务跟踪这几部分的开发，因为这个阶段中可能还要回头修改已完成的部分让这几个部分配合的更好，联调的工作量也多了不少，这个过程大概要2.5月。 而后随着业务逐渐增多，流量逐渐增加，为避免被黑产“薅羊毛”需要把服务安全部分给完成，同时为了快速响应新的业务需要把接口框架给完成，但此时有些同学会被已完成部分的日常维护、修bug等，这些初步需要两个月时间。 在这里都完成后，可以开始自动化测试、自动化部署这部分，也按照两个月的时间，这样一轮下来总体需要8个月时间。 经过第一轮后微服务的基础实施是有了，但要真正的运作起来还需要经过几轮的迭代才可以，但此时面对老系统的维护新系统的开发整体的进度会变慢不少，这样一个合格的比较完善的微服务基础设施差不多要两年时间了。作者回复: 你是第一个认真分析且抓住重点的同学👍👍
2018-09-1810238- Coder4看怎么定义自研了，今年花了1个月，每天半小时代码。半开源，半代码，已经实现了 服务发现，追踪，自动部署，以及后端服务数据库，消息队列，缓存，内存数据库的对接， 真正熟悉了，花不了太多时间，另外得合理利用轮子。
作者回复: 你这个太牛了，惊为天人啊😄
2018-07-1961 
无痕老师，很多人把oauth2的鉴权放到了网关，这个你怎么看作者回复: 不符合网关的定位，因为有的业务要鉴权有的不要，放在网关就相当于网关要和业务耦合了
2018-07-20521
程启华仔老师， 之前看您留言提到过service mesh不成熟，中小公司不建议使用。请问看起来最近gcp云平台，主推的k8s加上Istio/envoy实现服务治理，您认为未来方向如何，这个是试用中小型团队的方案吗？感谢解答！作者回复: 我没有service mesh具体实践经验，主要信息来源于网上资料，意见供参考。 1. Istio刚发布1.0版本，spring cloud成熟很多 2. service mesh中文为服务网格，很形象，说明了更加适合非常多的服务节点，简单来说，如果你只有一两个服务没必要用微服务架构，你只有几十个微服务节点可能也不需要service mesh 3. service mesh对程序无侵入，这点非常好，但随着spring cloud之类的方案成熟，侵入问题其实不是主要问题 因此，我认为大部分中小公司目前不需要service mesh，能把微服务做好已经很不错了。
2018-08-1218
成功30天左右作者回复: 太乐观，30天就算用spring全家桶，都不可能上线的
2018-07-27313
每天学英语的小沈微服务这两章讲的非常好，解决了长久以来的困惑作者回复: 都是实战经验总结
2019-01-099
水云波老师，你说API网关的主要包括接入鉴权、权限控制，然后在留言中又说不应该把oauth2的鉴权放到网关。我觉得前后矛盾了，是我对鉴权和权限控制哪里理解的还不到位吗？作者回复: oauth2是第三方授权，API网关是二方授权，二方是公司内不同业务部门的请求方和调用方，第三方授权是外部系统，内部系统，用户这三方
2019-06-1125- Geek_steven_wang华哥，你好！请问：服务间的安全策略通过配置中心下发给各节点，一般采用那些安全策略？我了解到的有黑白名单（根据服务名、IP），这个方案比较容易伪造（服务名和IP），还有其它策略吗？
作者回复: 内部网络需要与外部隔离，因此内部反而一般黑白名单用的少，因为机器会经常变，黑白名单管理比较麻烦；通常是给每个服务分配服务名称+服务访问密码之类的做法
2020-01-054 
空档滑行工作量需要看这一套框架要应对的服务规模和流量。以100个微服务，接口平均qps100以下做了简单测算，不考虑同城和异地多活，达到基本可用的话 配置中心，包括配置项管理和推送，和微服务一起打包的客户端 接口框架，使用http和Json的话，只需要一种语言的解析包 Api网关，后端服务对接和接入层实现 服务发现，使用自理式，注册中心服务端加客户端，加注册中心高可用 服务路由，相对简单 服务容错，包括熔断和流控等 服务监控，包括采集和分析 跟踪，各端trace注入，数据上传，数据查询和计算 安全，权限控制，配置支持 按10个高级开发，3人一组的话，大概半年左右作者回复: 半年只能出最简单的版本，不完善
2018-07-194
依乐祝看了这么久第一次留言，老师你好，刚看你说网关层不建议做鉴权！但是如果这样的话，那内部微服务之间如何进行通信呢？我的理解是网关做与url有关的权限处理！而具体的业务服务里面做与数据相关的权限鉴别！这样职业分开！然后内部进行通信的话就可以采用rpc进行高效的交互，而且都是可信的！不知道我的理解是否有误，还请老师指正下哈作者回复: 这样是可以的，网关鉴权仅限于和用户相关的登录态，登录环境等，业务权限还是要业务做
2019-01-033
