微服务架构概述---扫盲片
不知从何而起，与微服务相关的技术已然成为检验一个程序员是否合格的第一要素，微服务这一名词无论是博客、社交媒体还是会议讲演 其热度绝对可以拔得头筹。可是当我试图百度出什么是微服务时，发现度娘的介绍含糊其辞，一个“新技术”也是足够让你微醺一会。
图1、百度对微服务架构的解释
然后试图搜些帖子看看，不过很少有人能讲清楚微服务到底是什么。于是便忍痛花了点银两买了这本名为《Spring Could 与Docker-微服务架构实战-第二版》周立著。开篇对于微服务的讲述比较清晰和易于理解，便着手以博客的形式记录下自己的学习经历，希望大家可以共同学习和自我提高。
1、微服务是什么
先来一段原汁原味的干货，也是硬货，来自Martin Fowler
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.
中文表述，微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务公用一个最小型的集中式管理，服务可用不同的语言开发，可以使用不同的数据存储技术。
总结一下：
1、Martin称微服务是一种风格，这是对微服务本质的理解。是风格而不是规则更不是准则。换言之，只有当我们真正需要微服务时，它才能发挥最大功效。而并非生拉硬套，一概而论。
2、将单一应用拆分成一组服务，这是对微服务做了什么的理解。微服务架构最基础的工作就是拆分原有单一的冗余应用程序。
3、服务间采用轻量级通信，这是对微服务间通信最本质的理解。当服务被拆分后，服务间需要频繁的通信，如此一来，轻量级的通信便是最佳选择。目前而言，HTTP 的 API便是公认的Best one。
4、微服务们可以独立部署，自动部署。当服务被拆分并且建立后，部署则是真实落地的最后一步，而微服务的独立部署意味着真正的服务解耦。
5、微服务可以使用不同语言，不同数据存储技术。它们已经被拆分出来，从原有的冗余独一应用变为具有自己独立功能的微小服务，自然可以使用不同的语言和数据库。有的可能更倾向于算法，有的可能更倾向于大数据。
图2、简单的微服务图解
值得注意的是，服务间的调用可是没有顺序的，他们之间可以任意相互调用。
2、微服务解决了什么问题
如果你所在的项目不是微服务架构，那么它的部署肯定是一个归档包（大多数是war包）包含所有功能的应用程序，统称它们为单体应用。而架构单体应用的方法论，就是单体应用架构。以某AO系统为例：
图3、某单体应用结构图
单一应用易于部署测试，且项目初期这样的项目都会运行良好。然而随着需求和业务的不断增加，越来越多的人加入开发团队，代码库也在飞速膨胀。慢慢地，原有的单体应用变得愈发臃肿，可维护性灵活性逐渐降低，维护成本也越来越高。下面列举出单一应用的诸多缺点。
1、复杂度高
单体应用的通病是便是，随着时间的累加，代码行数也不断累加，混乱堆砌，模块的边界逐渐模糊不清，每次修改都是胆战心惊，一个小小的功能增加或者修改一个bug都可能带来无法预料的隐患，所有人在项目后期都是蹑手蹑脚。
2、技术债务
由于大家都不敢过多触碰代码，这种策略所有人都感同身受，不坏不修嘛。可是这会给单体应用带来技术债务，且逐步累加。
3、 部署频率低
单体应用中，每次小的变更都需要重新部署，但是单体应用部署的方式耗时长、影响范围大、风险高，这使得单体应用项目上线部署不得不降低频率。部署频率低，又会使得两次部署之间存在大量的变更和缺陷修复，出错频率比较高。
4、可靠性差
一个小小的bug或者死循环或者OOM都可能导致整个应用的瘫痪。
5、扩展受限
单体应用中各模块之间所完成的功能不同所以他们需要的不同的环境甚至是开发语言，可是在一个单体应用中这几乎是不可能的，你总得取舍。这样一来，单体应用的可扩展性大大受限。
6、阻碍技术创新
单体用用使用的同一平台解决方案，使得运用新技术的可能大大降低。因为更换架构中的某个技术点会使得成本过于昂贵。例如，我们想用Spring MVC更换Struts2。
所以，当你对比微服务时，你会发现它所解决的问题正是单体应用存在的问题。将原有的高耦合度单一应用拆分为具有一定颗粒度的单一微小服务，服务间采用轻量级通信，服务被集中管理和治理。如此一来，各个服务间可以使用自己独立的开发语言和存储技术，甚至任何你想使用的技术。且这些被拆分出的微小服务由于颗粒度较之“母体”单一应用，体积量级都减少了很多倍，无论独立维护还是开发都完全可以解耦。换言之，我们可以独立开发各服务而不受任何服务的影响，一荣俱荣一损俱损的局面也被打破。
3、微服务的优缺点
相对单体应用微服务的优点非常显著，但是任何事物都有两面性，微服务也不例外。我们罗列一下微服务的优缺点。
1、优点
- 易于维护和开发
- 单体服务启动较快
- 局部修改容易部署
- 技术延伸不受限制
- 按需伸缩
实际上，微服务就是对单体应用的一次升级，所以它的优点正是解决所有单体应用存在的实际问题。
2、缺点
- 运维要求较高
- 分布式固有的复杂性
- 接口调整要求高
- 重复劳动
值得注意的是微服务的缺点其实更多的是微服务面临的挑战，因为当我们重新认识原有的单一应用，试图通过微服务架构风格解决单一应用的不足时，我们必定面临新的问题，如上所示。在此不多解释上述缺点，我们可以结合微服务的概念进行理解。
4、微服务设计原则
理解微服务的设计原则是建立在理解为服务理念的基础上的。
- 单一职责原则
我们熟知的单一职责是one method do one thing。在微服务中应该是单一服务只关注于一件业务，例如部门服务只关注于部门的独立业务。
- 服务自治原则
服务自治是指每个服务应具备独立的业务能力、依赖与运行环境。在微服务架构中，服务是独立的业务单元，应该与其他服务高度解耦。每个服务从开发、测试、构建、部署都应该独立运行，而不是依赖其他服务。
- 轻量级通信机制
微服务之间应该通过轻量级的通信机制进行交互。体量小、跨平台，即为轻量级。
- 微服务颗粒度
微服务的颗粒度是技术主要难点，也是最具争议的地方。应当使用合理的颗粒度而不是越小越好。代码量的多少不能作为微服务的划分标准，因为服务本身业务不同代码量自然会不同。
5、微服务如何落地
相对于单体应用的交付，微服务应用的交付要复杂很多，不仅需要开发框架的支持，还需要一些自动化的部署工具。对于技术选型有如下要点：
- 开发框架
目前最火热也是首选的框架是SpringColud，其具备开箱机用的生产特点，可以大大的提高开发效率，其次文档丰富社区活跃。当然还有Dubbo、Dropwiz-ard、Armada其他框架。
- 运行平台
微服务并不绑定运行平台，将微服务部署在PC Server 或者阿里云、AWS等云计算平台也是可以的。
在第一章节中，只是让我们对微服务的概念以及理念和主要技术框架，优缺点等简单了解，单单一章节当然是无法完全描述清楚微服务的，但是作为扫盲的概念片绝对是足以。望诸君可以共勉，继续发学习微服务架构风格。
关于落地，这里是转载自另一个帖子的内容，我觉得更为详尽：
- 服务开发
- 服务的配置与管理
- 服务的注册与发现
- 服务的调用
- 服务的熔断器
- 负载均衡
- 服务接口调用
- 服务配置中心管理
- 服务监控
- 全链路追踪
- 服务部署
- 数据流操作开发包
- 时间消息总线
。。。。。。待更新