恋

什么是微服务

首先微服务并没有一个官方的定义，想要直接描述微服务比较困难，我们可以通过对比传统WEB应用，来理解什么是微服务。

传统的WEB应用核心分为业务逻辑、适配器以及API或通过UI访问的WEB界面。业务逻辑定义业务流程、业务规则以及领域实体。适配器包括数据库访问组件、消息组件以及访问接口等。一个打车软件的架构图如下：

尽管也是遵循模块化开发，但最终它们会打包并部署为单体式应用。例如Java应用程序会被打包成WAR，部署在Tomcat或者Jetty上。

这种单体应用比较适合于小项目，优点是：

• 开发简单直接，集中式管理
• 基本不会重复开发
• 功能都在本地，没有分布式的管理开销和调用开销

当然它的缺点也十分明显，特别对于互联网公司来说：

• 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断
• 代码维护难：代码功能耦合在一起，新人不知道何从下手
• 部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长
• 稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉
• 扩展性不够：无法满足高并发情况下的业务需求

小结

所以，现在主流的设计一般会采用微服务架构。其思路不是开发一个巨大的单体式应用，而是将应用分解为小的、互相连接的微服务。一个微服务完成某个特定功能，比如乘客管理和下单管理等。每个微服务都有自己的业务逻辑和适配器。一些微服务还会提供API接口给其他微服务和应用客户端使用。

比如，前面描述的系统可被分解为：

每个业务逻辑都被分解为一个微服务，微服务之间通过REST API通信。一些微服务也会向终端用户或客户端开发API接口。但通常情况下，这些客户端并不能直接访问后台微服务，而是通过API Gateway来传递请求。API Gateway一般负责服务路由、负载均衡、缓存、访问控制和鉴权等任务。

微服务架构的优点

微服务架构有很多重要的优点。首先，它解决了复杂性问题。它将单体应用分解为一组服务。虽然功能总量不变，但应用程序已被分解为可管理的模块或服务。这些服务定义了明确的RPC或消息驱动的API边界。微服务架构强化了应用模块化的水平，而这通过单体代码库很难实现。因此，微服务开发的速度要快很多，更容易理解和维护。

其次，这种体系结构使得每个服务都可以由专注于此服务的团队独立开发。只要符合服务API契约，开发人员可以自由选择开发技术。这就意味着开发人员可以采用新技术编写或重构服务，由于服务相对较小，所以这并不会对整体应用造成太大影响。

第三，微服务架构可以使每个微服务独立部署。开发人员无需协调对服务升级或更改的部署。这些更改可以在测试通过后立即部署。所以微服务架构也使得CI／CD成为可能。

最后，微服务架构使得每个服务都可独立扩展。我们只需定义满足服务部署要求的配置、容量、实例数量等约束条件即可。比如我们可以在EC2计算优化实例上部署CPU密集型服务，在EC2内存优化实例上部署内存数据库服务。

第一代微服务框架

Spring Cloud

Spring Cloud为开发者提供了快速构建分布式系统的通用模型的工具（包括配置管理、服务发现、熔断器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话、集群状态等）。

Dubbo

Dubbo是一个阿里巴巴开源出来的一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。

下一代微服务：Service Mesh？

Service Mesh

Service Mesh又译作“服务网格”，作为服务间通信的基础设施层。如果用一句话来解释什么是Service Mesh，可以将它比作是应用程序或者说微服务间的TCP/IP，负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心TCP/IP这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用Service Mesh也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如Spring Cloud、OSS，现在只要交给Service Mesh就可以了。

Java高并发框架

2018确实是微服务大发展的一年，特别是spring cloud框架在spring boot 2.0的支持下，配置和使用都方便了很多，但是，微服务不仅仅是把功能拆分而已，它对设计、实施、部署、运维甚至团队的组织结构都有很大的影响。

下面浅谈一点自己的感受：

1. 对设计的影响，传统的单体式项目，设计时大都是按照分层的思维来进行的，在同一层上，各种功能是聚合的，如果是小项目还OK，大项目经常出现牵一发而动全身的情况，给维护带来了很大的困难。但是在微服务下，更多的是按照领域驱动设计的思路，一个领域设计成一个独立的微服务，接口、缓存、持久化等相关动作都在该领域内，对外提供公共的服务，更易于维护。
2. 对部署的影响，微服务通过注册中心的机制，把服务提供方和消费方隔离开来，从而可以独立的部署各个服务，结合服务调用的负载平衡机制，可以通过部署多个服务实例的方式，进行不停机升级，就像开着车换轮子一样，服务消费方感觉不到服务提供方的服务已经升级了。
3. 对运维的影响，这一点更多的是被动的影响，只说一个简单的例子，就是系统日志，原来单体的时候日志在一个地方出来，现在使用微服务，日志会在多个甚至几十个微服务部署点出现，这直接就要了运维的老命了，所以日志的集中处理就是必须要做的事情了，这点也有成熟的方案，使用ELK stack能完美的解决这个问题，代价就是增加了对elasticsearch、logstash、kibana这三个服务本身的维护。
4. 对配置的影响，这一点类似于日志的集中处理，也可以对每个微服务的配置进行集中管理，spring cloud提供了内置解决方案，当然也有代价，如果不是特别多的微服务，可以不使用集中配置。
   
5. 对团队的影响，这一点非常明确，应该算是积极的影响，就是可以通过独立的小团队维护单个的微服务，小团队负责所有的和微服务相关的设计、开发、运维，不需要频繁的和其他团队交互，只要保证自己的服务稳定即可。

關鍵字: 服务 Java 互联网