微服务与微服务架构

最近在学习微服务，比较流行的就是阿里的Dubbo和Spring Cloud，不过目前使用Spring Cloud越来越多

微服务:

     强调的是服务的大小，它关注的是某一个点，是具体解决某一个问题/提供落地对应服务的一个服务应用

    从技术方面理解:微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底地去耦合,每一个微服务提供单个业务功能的服务，一个服务做一件事，从技术角度看就是一种小而独立的处理过程，类似进程概念，能够自行单独启动或销毁，拥有自己独立的数据库。

微服务架构：

      是⼀种架构模式，它提倡将单⼀应⽤程序划分成⼀组⼩的服务，服务之间互相协调、互相配合，为⽤户提供最终价值。每个服务运⾏在其独⽴的进程中，服务与服务间采⽤轻量级的通信机制互相协作（通常是基于HTTP协议的RESTful API）。每个服务都围绕着具体业务进⾏构建，并且能够被独⽴的部署到⽣产环境、类⽣产环境等。另外，应当尽量避免统⼀的、集中式的服务管理机制，对具体的⼀个服务⽽⾔，应根据业务上下⽂，选择合适的语⾔、⼯具对其进⾏构建。

可以去看一篇马丁大叔的文章，对微服务的理解  https://martinfowler.com/articles/microservices.html  中文翻译的网上也很多

目前学习的是Spring Cloud,Spring Cloud微服务涉及到的技术栈:

    服务开发    Springboot、Spring、SpringMVC    
    服务配置与管理    Netflix公司的Archaius、阿里的Diamond等    
    服务注册与发现    Eureka、Consul、Zookeeper等    
    服务调用    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    

 

 

比较一下传统的单体应用与微服务的特点以及优缺点

测试部署:

      单体架构测试、部署成本高：业务运行在一个进程中，因此系统中任何程序的改变，都需要对整个系统重新测试并部署

      微服务每个微服务组件都是简单灵活的，能够独立部署。不像单体系统，需要一个庞大的应用服务器来支撑

伸缩性：

      单体架构可伸缩性差：单体架构系统由于单进程的局限性，水平扩展时只能基于整个系统进行扩展，无法针对某一个功能模块按需扩展。例如：电商系统，包含了 用户、商品、订单、交易、支付；如果商品的访问量非常大，我想对商品进行集群部署，这时你是无法做到，你只能对整个系统进行集群部署。

      微服务之间是松耦合，微服务内部是高内聚，每个微服务很容易按需扩展。水平扩展只要按服务进行扩展即可。

可靠性：

      单体架构可靠性差：某个BUG，例如死循环、内存溢出，会导致整个进程宕机，影响整个系统，影响其他功能。

      微服务不会因为某个bug,而导致整个系统宕机。因为服务之间是松耦合的关系，不是强依赖。

系统迭代：

      单体架构迭代困难：由于所有的功能都在一个系统里面，会导致日常迭代相当困难，例如互联网项目，多个项目每月都有一次正常迭代，必定导致代码分支过多，分支合代码繁琐困难。

      微服务由一个小团队负责更专注专业，相应的也就更高效可靠。每个微服务可以由不同的团队独立开发。

跨语言程度：

      单体架构整个系统（甚至整个企业）统一的技术栈，管理起来看似简单。但有时候统一的标准并不适合所有的实际情况。

      微服务架构与语言工具无关，自由选择合适的语言和工具，高效的完成业务目标即可。

团队协助：

      单体架构整个系统一个团队。如果系统变得庞大，成员就需要学习大量的代码和领域知识，团队内的沟通和协作也变得低效。

      微服务 团队按微服务配置。成员专注于小的领域和代码集。沟通成本低。容易学习

 

同时微服务也会带来一定的问题

      1.运维成本过高，部署物数量多、监控进程多导致整体运维复杂度提升。

      2.接口兼容多版本（面向服务开发，就是面向接口开发，一般接口的变更，必然导致多个客户端要跟着改，那怎么办呢，就必须做接口的多版本开发）

      3.分布式系统的复杂性（本来就一个系统，把他拆成多个服务，就会引发，网络延迟（因为网络不稳定）、服务容错性、服务的负载均衡等等）

      4.分布式事务（微服务开发，带来的难题就是分布式事务的处理，在分布式事务这块其实也有很多解决方法）