一、前情概要
1、单体架构是什么
1)、一个归档包包含了应用所有功能的应用程序， 我们通常称之为单体应用。
2)、架构单体应用的架构风格， 我们称之为单体架构， 这是一种比较传统的架构风格。
2、单体架构存在的缺点
l 复杂性逐渐变高
l 技术债务逐渐上升
l 部署速度逐渐变慢
l 阻碍技术创新
l 无法按需伸缩
3、架构的演进
l 单体架构
l SOA
l 微服务
l 复杂性逐渐变高
l 技术债务逐渐上升
l 部署速度逐渐变慢
l 阻碍技术创新
l 无法按需伸缩
二、微服务HOT？Why?
1、微服务是什么？
节选自文章：http://www.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.
翻译：简而言之，微服务架构风格这种开发方法，是以开发一组小型服务的方式来开发一个独立的应用系统的。其中每个小型服务都运行在自己的进程中，并经常采用HTTP资源API这样轻量的机制来相互通信。这些服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写，并且可以使用不同的数据存储技术。对这些微服务我们仅做最低限度的集中管理。
l Martin Fowler：简而言之，微服务架构风格这种开发方法，是以开发一组小型服务的方式来开发一个独立的应用系统的。其中每个小型服务都运行在自己的进程中，并经常采用HTTP资源API这样轻量的机制来相互通信。这些服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写，并且可以使用不同的数据存储技术。对这些微服务我们仅做最低限度的集中管理。
l 来自：http://www.martinfowler.com/articles/microservices.html
2、微服务解决了什么问题？
解决了更新某个模块时，会重新部署整个项目的问题。微服务的模块单独划分，可以单独更新某个模块而其它模块不受影响；模块之间的使用的语言也可以互不相同。
3、微服务具备的特性？
l 1. 每个微服务可独立运行在自己的进程里；
l 2. 一系列独立运行的微服务共同构建起了整个系统；
l 3. 每个服务为独立的业务开发，一个微服务一般完成某个特定的功能，比如：订单管理、用户管理等；
l 4. 微服务之间通过一些轻量的通信机制进行通信，例如通过REST API或者RPC的方式进行调用；
l 5. 可以使用不同的语言和数据存储技术；
l 6. 全自动的部署机制。
4、微服务优点
1、易于开发和维护
一个微服务只关注一个特定的业务功能，所以他的业务清晰、代码量较少。开发和维护单个微服务相对是比较简单的。而整个应用是由若干个微服务构建而成所以整个应用也会维持在可控状态。
2、启动较快
单个微服务代码量较少，所以启动会比较快。
3、局部修改容易部署
单体应用还要有修改,就得重新部署整个项目，微服务解决了这样的问题。一般来说对某个微服务进行修改，只需重新部署修改的这个微服务即可。
4、技术栈不受限
在微服务中，我们可以结合项目业务及团队的特点，合理的选择技术栈。例如某些服务可使用关系型数据库Mysql；某些微服务有图形计算的需求，我们可以使用Node 4J；甚至可以根据需要，部分微服务使用Java开发，部分微服务使用NodeJS 进行开发。
5、按需伸缩
我们可以根据需求，实现细粒度的扩展。例如：系统中的某个微服务遇到了瓶颈，我们可以结合这个微服务的业务特点，增加内存、升级CPU或者是增加节点。
6、DevOps
DevOps（英文Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。
5、微服务架构的挑战
1、运维要求较高
更多的服务意味着更多的运维投入。在单体架构中，只需要保证一个应用的正常运行；而在微服务中，需要保证几十甚至几百个服务的正常运行与协作，这给项目的运维带来了很大的挑战。
2、分布式固有的复杂性
使用微服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都给我们带来了很大的挑战。
3、接口调整成本高
微服务之间通过接口进行通信。如果修改某一个微服务的API，可能所有使用了该接口的微服务都需要做调整。
4、重复劳动
很多服务可能都会使用到相同的功能，而这个功能并没有达到分解为一个微服务的程度，这个时候，可能各个服务都会开发这一功能，从而导致代码重复。
三、微服务设计原则
0、能不能做成微服务，取决于四个要素：
-
小：微服务体积小，2 pizza 团队。
-
独：能够独立的部署和运行。
-
轻：使用轻量级的通信机制和架构。
-
松：为服务之间是松耦合的。
1、单一职责原则
每个微服务只需要实现自己的业务逻辑就可以了，比如订单模块，它只需要处理订单的业务逻辑就可以了，其它的不必考虑。
更多课参考维基百科：https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
2、服务自治原则
服务自治，是指每个微服务应该具备独立的业务能力、依赖与运行环境，包括存储的数据库也都是独立的，自己就有一套完整的流程。我们完全可以把它当成一个项目来对待，不必依赖于其它模块。
3、轻量级通信原则
首先是通信的语言非常的轻量，第二，该通信方式需要是跨语言、跨平台的，之所以要跨平台、跨语言就是为了让每个微服务都有足够的独立性，可以不受技术的钳制。
4、接口明确原则
每个服务的对外接口应该明确定义，并尽量保持不变。