如果让你为 1000 人的公司内网搭建微服务并选择 API 网关，你会从何入手？
回答·94
最热
最新
- 首先考虑人员分布，1000 人的公司研发占比按照 40%来计，就意味着有 400 人研发。如果在进一步拆分，运维、数据、前段、后端、算法、等。实际会接触到微服务开发的研发力量究竟有多少这个要先清楚。假设应用研发在整体 400 的技术团队中占比 1/3，那就是代表有约 130 人是会接触到微服务开发的。 接下来就是考虑 130 研发队伍中组织架构如何协调。如果是垂直拆分了多个大部门，各自独立决策技术选型，那么很可能一个公司中会存在多种网关，此时再选网关一定重要考虑接入多重能力。 再下来要考虑一下业务量，越重要的越适合自建。这个重要不是拍脑袋决定而是要有数据说话，比如承载了大部分业务，而且都是核心业务。 不重要或者没啥量，不要自建 roi 不高。
- 得先入职，才能搭建。兼职工作不可取。这个问题能得到技术答案，又不用招人，妙哉。
- 权限安全，流量控制，路由控制，API 聚合，应用监控，灵活扩展 方向考虑
- 微服务架构用 Spring boot 来构建，api 网关用 zuul/或者 nginx 来进行不同服务类型的分发，比如根据业务逻辑进行服务拆分，或者不同的客户端，比如 pc 还是 app 来进行分发，微服务通过 nacos 或者 eureka 来进行服务注册和负载均衡。 微服务的架构和技术选型：spring boot/feign/ribbon，限流用 alibaba 的 sentinel，或者 Netflix 的 hystrix 高并发场景用多级缓存，本地缓存 guava，redis 集群，消息队列（rabbitmq/kafka）来异步操作，netty 做 nio 根据需要 存储层用 jpa/mybatis，分布式事务用 seata cicd 用 jenkins 来做持续集成，用 docker 做所有的微服务组的容器化部署 日志用 elk，监控用 peometheus/grafana。
- S1:梳理每个人业务需求及流程; S2:业务模块化设计，区分私有模块和公共模块； S3:模块关系模型设计，调用流程与鉴权分析与设计； S4:模块间调用接口及协议设计； S5:根据模块使用频率、效率、资源消耗等情况初步规划微服务水平、垂直纬度架构； S6:微服务间调用接口分析设计，区分私有接口和公共接口； S7:为公共微服务接口设定调用逻辑及鉴权策略，形成 API 网关 S8:试运行一段时间，根据实际运行监测数据，对照以上设计进行相应调整优化
- 好多小公司喜欢问如何抗百万并发，实际上一天也就几千个访问量
- KONG+nacos+Springboot+Kubersphere+cas+权限平台。 其实现在有大把的工具可以很快捷的帮助一个企业快速构建其 IT 信息化平台。 关键问题在于老板对资源利用率，信息安全的管控要求。是否支持你做信息化规范，需求规范，数据规范，接口规范这些都是没啥绩效的东西，开发人员业务抽象能力不达标，老板不能信任你的话，把应用拆开来按微服务方式部署就行了。
- 需要莫大的魄力，顶得住各方压力，还要收拾得了各种甩锅。
- 1000 人也就是最大 300 并发，这个下只需要利用好缓存，单数据库结构就可以了，不需要微服务，那样只会增加成本，考虑到将来 5 到 10 年内的扩展，应用做成 dock 加 k8s，nacos 管理，路由 nginx 转网关就可以了！
- 我辉告诉他们，他们不需要这玩意儿
相似问题
推荐关注
正在加载中...