微服务

微服务这一概念出现于2012年，是因软件作者Martin Fowler而流行。后来我了解到我工作所开发的产品就可以称之为微服务产品，但是具体工作所接触的内容不多，所以要对微服务来进一步学习一下。

首选想找微服务的定义，于是就有了下面一段话：

a definition of this new architectural term

The term “Microservice Architecture” has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.

这段话来自于https://martinfowler.com/articles/microservices.html，是马丁福勒个人博客上对于微服务的定义，虽然马丁福勒并不是微服务的创始人，但正是由于此人，微服务才被大家所熟知，这段定义翻译过来就是：

一种新的架构术语的定义
过去几年中，出现了“微服务架构”这一术语，来描述将软件应用程序设计为可独立部署的服务套件的特定方法。虽然没有对这种架构风格的精确定义，但是围绕着业务能力，自动部署，智能节点以及语言和数据的分散化控制等方面有一些共同特征。

那么这些特征是什么呢？

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.

– James Lewis and Martin Fowler (2014)

简单来说，微服务架构风格就是一种将单个应用程序开发为一套小型服务，每个服务运行在其独立的进程中，服务之间采用轻量级的通信机制（通常是基于HTTP的API，比如Rest API）。每个服务都围绕着具体业务进行构建，可通过全自动部署机制独立部署。这些服务应尽量避免集中式管理，可以使用不同的语言来编写服务，也可以使用不同的数据存储技术。

微服务的核心就是将传统的一站式应用，根据业务拆分成多个小的服务，彻底去耦合，每一个微服务提供单个业务功能的服务；从技术角度看，每一个服务都拥有自己独立的进程，能够自行单独启动或销毁，拥有自己独立的数据库。

微服务强调的是服务的大小，它关注的是某一个点，是具体解决某一个问题或者提供落地对应服务的一个服务应用。狭义的看，可以看做是Eclipse中用maven开发的一个个独立的module，它具体时间使用Spring Boot开发的一个小模块，一个模块就做一件事情。

微服务优缺点：

• 优点：
  • 每个服务都很小，每个服务可独立运行在自己的进程里，可独立承担部分业务功能
  • 内聚性好，代码容易理解，开发简单，效率高，易维护
  • 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的，所以也易扩展
  • 微服务能使用不同的语言开发，易与第三方集成，允许你利用融合最新技术，技术栈不受限
  • 微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins、Hudson、bamboo
  • 微服务只是业务逻辑的代码，不会和HTML、CSS或其它界面组件混合
  • 每个微服务都有自己的存储能力，可以有自己的数据库，也可以有共享的数据库
• 缺点：
  • 开发人员需要处理分布式系统的复杂性
  • 随着服务的增大，系统架构庞大，运维成本高
  • 系统部署依赖
  • 服务间通信成本
  • 数据一致性
  • 系统集成测试
  • 性能监控…

微服务设计原则

1. 单一职责原则
   和设计模式中的单一职责原则类似，每个微服务只需要实现自己的业务逻辑，其它的无需考虑。
2. 服务自治原则
   每个微服务的开发、测试、运维等都是独立的，包括存储的数据库也都是独立的，完全可以作为一个独立的项目来对待。
3. 轻量级通信原则
   为了保证微服务之间的通信成本尽可能小，所以保持轻量级通信。RESTful HTTP是微服务架构最常用的通信机制。
4. 接口明确原则
   由于微服务之间可能存在调用关系，或者对外的接口设计，要尽量避免接口的变化，避免对其它模块以及用户的影响。

微服务技术栈，慢慢研究

微服务功能	成熟的技术
服务开发	Springboot、Spring、SpringMVC
服务配置与管理	Netflix的Archaius、阿里的Diamond等
服务注册于发现	Eureka、Zookeeper、Consul等
服务调用	Rest、RPC、gRPC
服务熔断器	Hystrix、Envoy等
负载均衡	Ribbon、Nginx等
服务接口调用（客户端调用服务的简化工具）	Feign等
消息队列	Kafka、RabbitMQ、ActiveMQ等
服务配置中心管理	SpringCloudConfig、Chef等
服务路由（API网管）	Zuul等
服务监控	Zabbix、Nagios、Metrics、Spectator等
全链路追踪	Zipkin、Brave、Dapper等
服务部署	Docker、Openstack、Kubernetes等
数据流操作开发包	SpringCloud Stream（封装与Redis、Rabbit、Kafka等发送接收消息）
事件消息总线	Spring Cloud Bus