-----学习笔记-----
为学透微服务，其中部分内容引自博客kunyus。
我们在前面两篇文章中已经介绍了云原生相关的概念及其应用，本课时开始我们将会进入微服务的相关学习。
微服务架构是当前流行的架构方式，在本课时我们将会首先介绍服务端架构的发展，如何由单体一步步演进到微服务架构；随后介绍Go语言微服务架构的选型，确定本课程的基本框架；最后，在学习完云原生和微服务的相关知识，我们再回顾一下云原生架构与微服务架构之间到底是什么关系。
服务端架构的演进
事情总在发展，大型软件系统架构也随着软件开发技术、基础配套设备和硬件性能等因素的改变而不断演化着。一般来说，早期的软件大多数是单体架构，接着使用分层技术演化为垂直架构，然后SOA面向服务架构和微服务架构相继登场，最终随着云技术的应用和推广而孕育出云原生架构的思想。下面我们就来一一介绍这些架构设计的基础理念和优缺点。
1.单体架构
在Web应用程序发展的早期，大部分工程是将所有的服务端功能模块打包成单个巨石型（Monolith）应用，譬如很多企业的Java应用程序打包为war包，最终会形成如下图所示的架构。
单体架构的应用程序
单体架构的应用开发简单，技术单一，测试、部署相对简单明了。但其缺陷也是非常明显的，进行局部改动就需要重新部署，而且编译时间过长。除此之外，单体架构的技术栈也不易扩展，只能不断地在原有基础上进行局部优化，比如说应用的某一场景需要处理高并发，使用Go语言较为合适，但是单体架构并不支持多语言技术栈，这时也就只好作罢。
2.垂直分层架构
单体架构在系统用户访问量逐渐增大的情况下，若仅仅依靠扩展物理机配置或者增加机器来优化系统的性能，往往收效甚微。单体架构中不同业务模块的差异就会显现，比如有些模块是IO密集型，有些是计算密集型。这些模块所需要的机器数量和性能各有差异，这时为了提升机器利用率和性能，垂直分层架构就诞生了。
垂直分层架构是将大应用拆分成一个个单体结构的应用。换句话说，垂直架构就是彼此存在依赖关系的组件组成的架构，比如分层——用户界面层依赖业务逻辑，而业务逻辑依赖数据库访问（如下图所示）。垂直分层是一个典型的对复杂系统进行结构化思考和抽象聚合的通用性方法。
垂直分层架构的应用程序
这样处理后，垂直分层架构就解决了很多问题：将系统拆分实现了流量分担，解决了部分并发问题；拆分之后，服务间相互独立；性能方面，可以针对单个服务模块进行优化；易于水平扩展，多实例提升容错率。
但其缺点也是明显的，垂直分层架构的系统拆分，使得集群搭建变得复杂；涉及的服务间调用，服务之间耦合度变高，调用关系错综复杂，难以维护调用关系。
3.SOA面向服务架构
当垂直架构拆分的应用越来越多时，就会出现多个应用都依赖的业务逻辑组件，并且各个应用进行交互的需要也越来越频繁。此时，就需要将部分通用的业务组件独立出来，并定义好服务间交互的接口，向外提供能力，让其他服务调用。SOA面向服务架构这就“应运而生”了。
SOA面向服务架构是一种软件体系结构，它将应用程序的不同服务通过定义良好的接口和契约联系起来，这些接口独立定义，不依赖实现服务的编程语言、操作系统。应用程序的不同组件通过网络上的通信协议向其他组件提供服务。通信可以是简单的数据传递，也可以是两个或多个服务彼此协调连接。
SOA面向服务架构
SOA面向服务架构中主要有两个角色：服务提供者和使用者。如上图所示，服务消费者可以通过发送消息来调用订单、购买、账号的服务，这些消息由服务总线转换后发送给对应的服务，实现SOA服务之间的交互通信。
SOA面向服务架构主要适用于大型软件服务企业对外提供服务的场景，至于一般业务场景就并不适用了，因为其服务的定义、注册和调用都需要较为烦琐的编码或者配置实现，并且业务总线也容易导致系统的单点风险并拖累整体性能。
4.微服务架构
随着互联网浪潮的来临，越来越多的中小微企业推出面向普通大众的网站或者应用。这些企业不同于大型软件服务企业，没有能力也无须构建SOA所依赖的ESB企业服务总线。于是继承SOA众多优点和理念的微服务架构于年由MatrinFowler提出，其理念是将业务系统彻底地组件化和服务化，形成多个可以独立开发、部署和维护的服务或者应用的集合，以应对更快的需求变更和更短的开发迭代周期。
首先了解什么是微服务架构?
通常而言，微服务架构是一种架构模式或者说是一种架构风格。
它提倡将单一应用程序划分成一组小的服务，每个服务运行独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。
服务之间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTfulAPI)。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。
再看微服务架构和单体架构的区别
A.单体架构
通俗地讲，“单体应用（monolithapplication）”就是将应用程序的所有功能都打包成一个独立的单元，可以是JAR、EXE、BIN或其它归档格式。
单体应用有如下优点：
开发简单直接，集中式管理,基本不会重复开发
功能都在本地，没有分布式的管理开销和调用开销。
它的缺点也非常明显，特别对于互联网公司来说：
开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断
代码维护难：代码功能耦合在一起，新人不知道何从下手
部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长
稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉
扩展性不够：无法满足高并发情况下的业务需求
##B.微服务架构
随着业务需求的快速发展变化，敏捷性、灵活性和可扩展性需求不断增长，迫切需要一种更加快速高效的软件交付方式。微服务就是一种可以满足这种需求的软件架构风格。单体应用被分解成多个更小的服务，每个服务有自己的归档文件，单独部署，然后共同组成一个应用程序。这里的“微”不是针对代码行数而言，而是说服务的范围限定到单个功能。
微服务有如下优点：
微服务是松藕合的，无论是在开发阶段或部署阶段都是独立的。
能够快速响应,局部修改容易,一个服务出现问题不会影响整个应用。
易于和第三方应用系统集成,支持使用不同的语言开发,允许你利用融合最新技术。
每个微服务都很小，足够内聚，足够小，代码容易理解。团队能够更