微服务架构简介

什么是微服务架构

微服务架构是指按业务与数据来源将统一的系统拆分成若干相对独立自治的子服务，各服务只实现特定功能（如登录服务只实现登录相关的逻辑），服务以接口的形式为应用或其他服务提供功能与数据（如订单服务调用登录服务的检查登录态接口来判断用户是否登录），这种按业务拆分系统的解决方案称之为微服务架构。

微服务架构的特点

微服务是指开发一组小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上。微服务也指一种种松耦合的、有一定的有界上下文的面向服务架构。也就是说，如果每个服务都要同时修改，那么它们就不是微服务，因为它们紧耦合在一起；它的主要特点是组件化、松耦合、自治、去中心化，体现在以下几个方面：

一组小的服务
服务粒度要小，而每个服务是针对一个单一职责的业务能力的封装，专注做好一件事情。

独立部署运行和扩展
每个服务能够独立被部署并运行在一个进程内。这种运行和部署方式能够赋予系统灵活的代码组织方式和发布节奏，使得快速交付和应对变化成为可能。

独立开发和演化 
技术选型灵活，不受遗留系统技术约束。合适的业务问题选择合适的技术可以独立演化。服务与服务之间采取与语言无关的API进行集成。相对单体架构，微服务架构是更面向业务创新的一种架构模式。

独立团队和自治 
团队对服务的整个生命周期负责，工作在独立的上下文中，自己决策自己治理，而不需要统一的指挥中心。团队和团队之间通过松散的社区部落进行衔接。

微服务优点

• 每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求。
• 微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。
• 每个微服务都可以有自己的存储能力，可以有自己的独立的数据库与缓存系统。
• 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
• 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
• 微服务中每个服务对资源的需求不同，可以按需为每个服务分配硬件资源，运维人员可按服务对资源的需求合理分配硬件资源。

微服务架构的行业现状

• 每个服务往往会有单独的日志，服务数量上去后，日志会很分散，排查问题需要登录具体服务器查看对应服务日志，往往缺乏日志集中管理功能。
• 每个服务中有很多重复配置，很多公司都缺乏统一配置平台，导致修改通用配置时需要更新所有相关服务的配置文件，容易出现更新失败或遗漏的情况。
• 架构人员往往盲目追求服务的横向拓展，导致服务拆分过细，将一个业务拆分为多个服务来满足性能要求，忽略了云服务器资源易扩展的优点。
• 微服务系统长期运行后，都会经历多次技术迭代，由于技术掌控者的变更或老的通讯协议不能满足新的业务场景通常会引入新的通讯协议，往往会出现多种通讯并在的情况，导致服务间的调度不能做到通用。
• 实际业务场景或生产部署时不能保证每个服务都对应独立的数据库与缓存，服务间可能会共享数据，一个服务也可能会有多个数据源，数据源权限管理很复杂，很容易写出跨库联表查询的代码，导致后续不可直接分库。

以上几点提升了微服务系统的运维成本，导致生产部署都需要开发人员参与，不能交付给运维人员，所以一个高效的微服务架构必需解决以下问题

• 集中配置，公共配置必需做到集中化管理，避免不的同服务出现重复配置。
• 日志集中化管理，服务日志可以通过消息队列(如kafka)转存到一个地方集中管理、统一分析或监控。
• 充分发挥云服务器资源可动态调节的优势，不要将服务拆分的太细，最好按业务与数据源对服务进行拆分。
• 公共数据接口化，比如说用户基本信息应该由用户服务提供接口给其他服务调用，而不是直接跨库联表查询。
• 架构设计时应面向未来，选择开放、通用的通讯协议，极力推荐http协议，各节点间协议一致，网关只做网络隔离、负载均衡等功能，不做协议转换。​