微服务架构设计模式——微服务架构
关于微服务架构的定义众说纷纭，所以我摘取了几个描述的比较清晰的定义在这供参考。
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.html
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.nginx
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-cloudgit
目前市面上作微服务还比较流行的组件有
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）github
目前Spring Cloud技术栈的对好比下图，因为Netflex逐渐将组件的开发状态转为维护状态，Pivitol公司可能面临后继乏力的危险，而Spring Cloud Alibaba正在慢慢发力，有可能在将来取代Spring Cloud造成微服务闭环的技术栈。spring
那么微服务架构是什么样的呢？
在Github上有个叫piggymetrics（https://github.com/sqshq/PiggyMetrics）的项目就很简单明了的展现了何为微服务架构，以下图，做者用Spring Boot， Spring Cloud和Docker等技术栈搭起来一个微服务的演示项目，服务与服务之间经过REST API通讯，每一个服务拥有独立的数据库数据库
下图更加详细的展现了微服务所用到的技术栈和各个微服务组件是如何在整个微服务架构中发挥做用的。apache
ZUUL： API路由
ELK STACK： 日志分析
HYSTRIX 和 RIBBON：负载均衡和熔断限流
EUREKA： 服务发现
TURBINE： 监控大盘
Spring Cloud Config: 分布式配置中心
OAuth2： 服务鉴权受权设计模式
微服务带来的好处不少，诸如
使大型复杂应用能够持续性发布和部署（采用DevOps的方式开发，小团队，屡次迭代，快速部署，单次部署风险小）
服务“微”容易维护（代码量较少，容易理解，开发快）
服务能够独立拓展（可根据应用的特性部署到不一样的机器，例如能够将CPU密集型应用和内存密集型应用部署到不一样机器，以充分发挥机器性能）
服务能够单独部署（松耦合，与其余服务的联系不强，自主性强）
新技术的采用更为方便（例如可使用Golang写的OAuth2进行鉴权受权，不须要所有使用同一种语言）
较强的容错性（Hystrix能够防止“雪崩”的产生，能够隔离故障，也能够根据条件进行服务降级， Ribbon实现软负载均衡，减轻单机压力）架构
固然，凡是都有两面性，没有绝对的“银弹”，微服务架构也会带来一些缺点，如
如何划分服务的边界，根据业务仍是根据何种规约
分布式系统带来的复杂性使得开发、测试和部署都增长难度
若是发布的特性设计多个服务，须要谨慎和多个团队合做
采用微服务的时机难以界定
数据的一致性很差维护
数据查询难，尤为是涉及到跨数据库app
对此，Chris Richardson也划分了多个架构模式来应对微服务架构所带来的种种问题，能够说好的架构是演化而来的，例如单体架构演化到微服务架构，能够经过应用设计模式、应用基础设施设计模式和基础设施设计模式多方面来解决微服务带来的问题。其余设计模式会在接下来的文章一一道来，我也会写一些相关的代码示例来更加形象展现微服务的实战，个人github地址：https://github.com/Guilai1990?tab=repositories
参考资料：
Martin Fowler我的网站 https://www.martinfowler.com/microservices/
Adopting Microservices at Netflix: Lessons for Architectural Design
Chris Richardson —— Microservice Patterns
Chris Richardson我的网站 https://microservices.io/patterns/microservices.html