微服务架构设计模式——微服务架构

关于微服务架构的定义众说纷纭，因此我摘取了几个描述的比较清晰的定义在这供参考。
1.网飞（Netflix）架构师给出的定义，所谓微服务架构就是服务导向，松耦合有边界的元素构成的架构，松耦合指的是可以独立更新服务，不会对其他服务造成影响。同时，对于数据库需要适当的拆分，有可能会违反规范。
Cockcroft defines a microservices architecture as a service‑oriented architecture composed of loosely coupled elements that have bounded contexts.
Loosely coupled means that you can update the services independently; updating one service doesn’t require changing any other services. If you have a bunch of small, specialized services but still have to update them together, they’re not microservices because they’re not loosely coupled. One kind of coupling that people tend to overlook as they transition to a microservices architecture is database coupling, where all services talk to the same database and updating a service means changing the schema. You need to split the database up and denormalize it.

2.Martin Fowler则认为微服务架构是一种开发一套小服务的方式（与SOA不同），服务间通过一些轻量级的方式通信，如HTTP（这也是为什么REST API近年来这么火）方式。这些围绕业务能力搭建的服务可以独立并且自动化的发布。因为微服务没有一个明确的核心，因此可以用不同的语言和存储技术来开发。
In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

Chris Richardson在他的书（design patterns）中给出了一个较为详细可操作性的关于微服务架构的阐述，通过三个象限的维度拓展应用，即多实例、路由和负载均衡、根据功能拆分，微服务的最小单元——服务，仅仅是一个功能的实现。微服务用大白话来说就是将原先的单体架构拆分成一个个小服务，粒度细化。
说到微服务，就避不开网飞这家公司，网飞是较早实现微服务架构的公司并且开源了一套完整的组件供其他公司使用，有
服务发现组件：eureka https://github.com/Netflix/eureka
负载均衡组件：ribbon https://github.com/Netflix/ribbon
限流熔断组件：Hystrix https://github.com/Netflix/Hystrix
路由监控组件：zuul https://github.com/Netflix/zuul
之后，Pivitol公司在这些组件上做了封装，也开发了一些其他组件组成了一套比较成熟完整的微服务生态
https://github.com/spring-cloud

目前市面上做微服务还比较流行的组件有
Web Service客户端： Spring Cloud Feign https://github.com/spring-cloud/spring-cloud-openfeign
API网关： Spring Cloud Gateway（目标是取代zuul）
分布式配置中心： Spring Cloud Config
阿里巴巴早先的微服务解决方案：Apache Dubbo（https://github.com/apache/dubbo）(该项目已通过Apache孵化，成为阿帕奇基金的顶级项目)
阿里巴巴微服务一站式解决方案：Spring Cloud Alibaba（https://github.com/spring-cloud-incubator/spring-cloud-alibaba）

目前Spring Cloud技术栈的对比如下图，由于Netflex逐渐将组件的开发状态转为维护状态，Pivitol公司可能面临后继乏力的危险，而Spring Cloud Alibaba正在慢慢发力，有可能在未来取代Spring Cloud形成微服务闭环的技术栈。

Spring Cloud技术栈对比

那么微服务架构是什么样的呢？
在Github上有个叫piggymetrics（https://github.com/sqshq/PiggyMetrics）的项目就很简单明了的展示了何为微服务架构，如下图，作者用Spring Boot， Spring Cloud和Docker等技术栈搭起来一个微服务的演示项目，服务与服务之间通过REST API通信，每个服务拥有独立的数据库

PiggyMetrics微服务架构图

下图更加详细的展示了微服务所用到的技术栈和各个微服务组件是如何在整个微服务架构中发挥作用的。

微服务组件的应用

ZUUL： API路由
ELK STACK： 日志分析
HYSTRIX 和 RIBBON：负载均衡和熔断限流
EUREKA： 服务发现
TURBINE： 监控大盘
Spring Cloud Config: 分布式配置中心
OAuth2： 服务鉴权授权

微服务带来的好处很多，诸如
使大型复杂应用可以持续性发布和部署（采用DevOps的方式开发，小团队，多次迭代，快速部署，单次部署风险小）
服务“微”容易维护（代码量较少，容易理解，开发快）
服务可以独立拓展（可根据应用的特性部署到不同的机器，例如可以将CPU密集型应用和内存密集型应用部署到不同机器，以充分发挥机器性能）
服务可以单独部署（松耦合，与其他服务的联系不强，自主性强）
新技术的采用更为方便（例如可以使用Golang写的OAuth2进行鉴权授权，不需要全部使用同一种语言）
较强的容错性（Hystrix可以防止“雪崩”的产生，可以隔离故障，也可以根据条件进行服务降级， Ribbon实现软负载均衡，减轻单机压力）

当然，凡是都有两面性，没有绝对的“银弹”，微服务架构也会带来一些缺点，如
如何划分服务的边界，根据业务还是根据何种规约
分布式系统带来的复杂性使得开发、测试和部署都增加难度
如果发布的特性设计多个服务，需要谨慎和多个团队合作
采用微服务的时机难以界定
数据的一致性不好维护
数据查询难，尤其是涉及到跨数据库

对此，Chris Richardson也划分了多个架构模式来应对微服务架构所带来的种种问题，可以说好的架构是演化而来的，例如单体架构演化到微服务架构，可以通过应用设计模式、应用基础设施设计模式和基础设施设计模式多方面来解决微服务带来的问题。其他设计模式会在接下来的文章一一道来，我也会写一些相关的代码示例来更加形象展示微服务的实战，我的github地址：https://github.com/Guilai1990?tab=repositories

参考资料：

Martin Fowler个人网站 https://www.martinfowler.com/microservices/

Adopting Microservices at Netflix: Lessons for Architectural Design

PiggyMetrics的Github

Chris Richardson —— Microservice Patterns

Chris Richardson个人网站 https://microservices.io/patterns/microservices.html