从单体应用到微服务架构演变的概述

1. 单体应用架构存在的问题
   一个归档包(例如war格式)包含所有功能的应用程序,通常定义为单体应用,而架构单体应用的方法论,就是单体应用架构。
   单体应用的好处: 容易部署丶测试。
   单体应用的劣势: 代码臃肿丶可维护性差丶可靠性差丶灵活性逐渐降低丶维护成本越来越高。

2. 如何解决单体应用架构存在的问题
   微服务能解决,那什么是微服务呢?
   
   目前来看微服务本身并没有一个严格的定义,每个人对微服务的理解都不同,网上的一种说法是"微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法,每个服务运行在自己的进程中,服务间采用轻量级通信机制(通常HTTP资源API)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式管理,服务可用不同的语言开发,使用不同的数据存储技术。"
   
   微服务特征:
   1.每个微服务可以独立运行在自己的进程里
   2.一系列独立运行的微服务共同构建起整个系统
   3.每个服务为独立的业务开发,一个微服务只关注某个特定的功能,例如订单管理,用户管理等...
   4.微服务之间通过一些轻量的通信机制来进行通信,例如通过RESTFUL API进行调用,
   5.可以使用不同的语言和数据存储技术
   6.全自动的部署机制             
    
3. 微服务架构的优点和挑战
    相对单体应用架构来说,微服务架构有着明显的优点。
    但是,微服务并非是完美的,使用微服务也为我们的工作带来的一些挑战
4. 微服务架构的优点
   优点:
   1.易于开发和维护：
        一个微服务只会关注一个特定的业务功能,所以业务清晰丶代码量较少,开发和维护单个微服务相对简单。而整个应用是由若干个微服务构建而成的,所以整个应用也会被维持在一个可控状态。
   
   2.单个微服务启动较快：
        单个微服务代码量较少,所以启动会比较快。
   
   3.局部修改容易部署：
        单体应用只要有修改,就得重新部署整个应用,微服务解决了这样的问题。一般来说,对某个微服务进行了修改,只需要重新部署这个服务即可。
   
   4.技术栈不受限：
         在微服务架构中,可以结合项目业务或者团队的特点,合理选择技术栈。例如某些服务需要使用关系型数据库Mysql,有些需要使用Nosql数据库。
   
   5.按需伸缩：
         可以根据需求,实现细粒度的扩展。例如,系统某个微服务遇到了瓶颈,可以结合这个微服务的业务特点,增加内存丶升级CPU或者增加节点。
5. 微服务架构面临的挑战
   挑战:
   1.运维要求较高：
           更多的服务意味着更多的运维投入。在单体应用架构中,只需要保证一个应用的正常运行。而在微服务中,需要baozheng几十甚至几百个服务的正常运行与协作,这给运维带来了很大的挑战。
   
   2.分布式固有的复杂性：
           使用微服务架构的分布式系统,对于一个分布式系统,系统容错,丶网络延迟丶分布式事物等都会带来巨大的挑战。
   
   3.接口调整成本高：
           微服务之间通过接口来进行通信,如果修改某个微服务的API,可能所有使用了该接口的微服务都需要做调整。
   
   4.重复劳动：
           很多服务可能都会使用到相同的功能,而这些功能并没有达到分解为一个微服务的程序,这个时候,可能各个服务都会开发这一功能,从而导致代码重复。
6. 微服务设计的原则
   原则:
   1.单一职责原则：
            单一原则指的是一个单元(类丶方法或者服务等)值应关注整个系统功能中单独丶有界限的一部分。
   
   2.服务自治原则：
            服务自治是指每个微服务应具有独立的业务能力丶依赖与运行环境。
   
   3.轻量级通信机制：
            微服务之间应该通过轻量级的同性机制进行交互。个人认为,轻量级的通信机制应该具备两点: 首先,它的体量较轻,其次它应该可以跨语言丶跨平台。REST协议就是一个典型的"轻量级通信机制"。
   
   4.微服务粒度：
             微服务的粒度是难点,也是常常争论的焦点。应当使用合理的粒度划分微服务,而不是一味的把服务做小。代码量的多少不能作为服务划分的依据,因为不同的微服务本身的业务复杂性不同,代码量也就不同。
7. 如何实现微服务架构,技术选型
   相比单体应用的交付,微服务应用的交付要复杂很多,不仅仅需要开发框架的支持,还需要一些自动化的部署工具
   以下从开发和运行平台两个维度考虑技术选型:
   
   1.开发框架的选择: 可使用Spring cloud 作为微服务开发框架。首先,Spring cloud具备开箱即用的生成特性,可大大提升开发效率,再者,Spring cloud的文档丰富,社区活跃,遇到问题容易解决,更牛逼的是,Spring cloud为微服务架构提供了完整的解决方案。
   当然,也可以使用其他的开发框架或者解决方案来实现微服务,例如Dubbo等....
   
   2.运行平台: 微服务并不绑定运行平台,将微服务部署在PC Server或者阿里云,AWS等云计算平台都是可以的。
    
8. 微服务&分布式的区别
   简单的说，微服务是架构设计方式，分布式是系统部署方式，两者概念不同
   
   分布式:
          将一个大的系统划分为多个业务模块，业务模块分别部署到不同的机器上，各个业务模块之间通过接口进行数据交互。区别分布式的方式是根据不同机器不同业务。
   
   分布式和微服的架构很相似，只是部署的方式不一样而已。
   
   微服务与分布式的细微差别是，微服务的应用不一定是分散在多个服务器上，它也可以是同一个服务器。
   
   微服务相比分布式服务来说，它的粒度更小，服务之间耦合度更低，由于每个微服务都由独立的小团队负责，因此它敏捷性更高，分布式服务最后都会向微服务架构演化，这是一种趋势， 不过服务微服务化后带来的挑战也是显而易见的，例如服务粒度小，数量大，后期运维将会很难
9. 分布式&集群的区别
   集群是个物理形态，分布式是个工作方式。
   分布式：一个业务分拆多个子业务，部署在不同的服务器上
   
   区别:
   1.分布式是指将不同的业务分布在不同的地方。而集群指的是将几台服务器集中在一起，实现同一业务
   2.分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。