为什么大公司一定要使用微服务？

微服务的推行需要依赖于很多底层基础设施，包括提供微服务的编译、集成、打包、部署、配置等工作，采用 PaaS 平台解决微服务从开发到运行的全生命周期管理，同时提供异构环境管理、容器资源隔离与互通、服务伸缩漂移、服务升级与回退、服务熔断与降级、服务注册与发现。

①最基本的基础设施

进程间通讯机制：微服务是独立进程的，需要确定之间的通讯方式。

服务发现+服务路由：提供服务注册中心，服务提供者和消费者通过服务发现获取服务的信息从而调用服务，实现服务的负载均衡等。

服务容错：微服务架构中，由于服务非常多，往往是一个服务挂了，整个请求链路的服务都受到影响。

因此需要服务容错，在服务调用失败的时候能够处理错误或者快速失败，包括熔断、Fallback、重试、流控和服务隔离等。

分布式事务支持：随着业务拆分为服务，那么有时候不开避免的就是跨服务的事务，即分布式事务的问题。

原则是尽量避免分布式事务，如果无法避免那么可以使用消息系统或者 CQRS 和 Event Sourcing 方案来实现最终一致性。

如果需要强一致性，则有两阶段提交、三阶段提交、TCC 等分布式事务解决方案。

②提升外部服务对接效率和内部开发效率

API 网关：负责外部系统的访问，跨横切面的公共层面的工作，包括安全、日志、权限控制、传输加密、请求转发、流量控制等。

典型的网关功能即对外暴露一个域名 xx.com，根据第一级目录做反向路由 xx.com/user，xx.com/trade。

每一级目录，如 user、trade 对应一个服务的域名。此外，API 网关也可以有服务编排的功能(不推荐)。

接口框架：规范服务之间通讯使用的数据格式、解析包、自解释文档，便于服务使用方快速上手等。

③提升测试和运维效率

配置中心: 运行时配置管理能够解决动态修改配置并批量生效的问题。包括配置版本管理、配置项管理、节点管理、配置同步等。

持续交付：包括持续集成、自动化部署等流程。目的就是小步迭代，快速交付。

持续集成：这一部分并非是微服务特定的，对于之前的单体应用，此部分一般来说也是必要的。

主要是指通过自动化手段，持续地对代码进程编译构建、自动化测试，以得到快速有效的质量反馈，从而保证代码的顺利交付。

自动化测试包括代码级别的单元测试、单个系统的集成测试、系统间的接口测试。

自动化部署：微服务架构，节点数动辄上百上千，自动化部署能够提高部署速度和部署频率，从而保证持续交付。

包括版本管理、资源管理、部署操作、回滚操作等功能。而对于微服务的部署方式，包括蓝绿部署、滚动部署以及金丝雀部署。

④进一步提升运维效率

服务监控：微服务架构下节点数目众多，需要监控的机器、网络、进程、接口等的数量大大增加，需要一个强大的监控系统，能够提供实时搜集信息进行分析以及实时分析之上的预警。

包括监控服务的请求次数、响应时间分布、最大/最小响应值、错误码分布等。

服务跟踪：跟踪一个请求的完整路径，包括请求发起时间、响应时间、响应码、请求参数、返回结果等信息，也叫做全链路跟踪。

通常的服务可以和服务监控做在一起，宏观信息由服务跟踪呈现，微观单个服务/节点的信息由服务监控呈现。服务跟踪目前的实现理论基本都是 Google 的 Dapper 论文。

服务安全：内网之间的微服务调用原则上讲应该是都可以互相访问写，一般并不需要权限控制，但有时候限于业务要求，会对接口、数据等方面有安全控制的要求。

此部分可以以配置的方式存在于服务注册中心中，和服务绑定，在请求时由做为服务提供者的服务节点进行安全策略控制。配置则可以存储在配置中心以方便动态修改。

在微服务数量很少的情况下，以上基础设施的优先级自上而下降低。否则，仅仅依赖人工操作，则投入产出比会很低。

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!