微服务现在是一个很火的概念，尤其是搞IT的大多数都对其有所了解。
到底火到什么程度呢？2016年有一个统计说，两千家企业里，30%在使用微服务，15%在实验开发和测试微服务架构，24%在学习微服务准备转型，只有剩下的30%的企业没有使用微服务。
微服务到底有什么好呢？微服务在2013年才被提出，短短几年就有这么快速的发展。
微服务架构能够实现由小型自主服务组成一个整体应用，各个组成部分之间是松耦合的，复杂性低，各个部分可以独立部署，修复bug或者引入新特性更容易，能够独立扩展，不同技术栈之间可以使用不同框架、不同版本库甚至不同的操作系统平台。
下面就自己对微服务架构的一些理解及网络上的一些资料收集，对其进行了一个漫谈式的汇总,以此与各位看官共勉。
目录：
1、概要介绍
2、与传统开发模式、SOA的区别
3、特性
4、优点
5、缺点
6、微服务框架应具备的功能
7、实践
下面基于自己的理解，系统性的漫谈了下微服务架构。
在此基础上基于Angular、Typescript、.Net(WCF)技术栈，一体化的打造了一套轻量级的微服务研发框架，目前已经开源。
开源地址：https://github.com/mqg007/CFCFrame。
demo地址：http://www.codefc.cn。
学习资源请参考：https://blog.csdn.net/mql007007/article/details/80094439
一、概要介绍
微服务定义：
微服务是指开发一个单个小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上。
微服务也指一种种松耦合的、有一定的有界上下文的面向服务架构。也就是说，如果每个服务都要同时修改，那么它们就不是微服务，因为它们紧耦合在一起；
如果你需要掌握一个服务太多的上下文场景使用条件，那么它就是一个有上下文边界的服务，这个定义来自DDD领域驱动设计。
微服务架构：
微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。
微服务的目的：
微服务的目的是有效的拆分应用，实现敏捷开发和部署。
关于微服务的一个形象表达见下图：
X轴：运行多个负载均衡器之后的运行实例
Y轴：将应用进一步分解为微服务（分库）
Z轴：大数据量时，将服务分区（分表）
二、与传统开发模式的区别
a、微服务 vs SOA
SOA喜欢重用(通过ESB集成系统)，微服务喜欢重写
SOA喜欢水平服务，微服务喜欢垂直服务
SOA喜欢自上而下，微服务喜欢自下而上
其中：SOA更关注企业规模范围，微服务架构则更关注应用规模范围
b、微服务vs单体开发
两者比较重要的不同是组件的服务边界：
单体开发:通常注重的是业务逻辑及UI，不集成数据，依赖于主服务程序，不能独立部署。整个应用整体打包部署。
微服务组件：通常注重的是UI、业务逻辑、数据集成于一体，可以独立部署。
三、特性
1、组件化(Componentizationvia Services)：
微服务架构中将组件定义为可被独立替换和升级的软件单元，在应用架构设计中通过将整体应用切分成可独立部署及升级的微服务方式进行组件化设计。
2、围绕业务能力组织服务(Organizedaround Business Capabilities)：
微服务架构采取以业务能力为出发点组织服务的策略，因此微服务团队的组织结构必须是跨功能的（如：既管应用，也管数据库）、强搭配的DevOps开发运维一体化团队。
3、产品而非项目模式(Productsnot Projects)：
传统的应用模式是一个团队以项目模式开发完整的应用，开发完成后就交付给运维团队负责维护；微服务架构则倡导一个团队应该如开发产品般负责一个“微服务”完整的生命周期，倡导“谁开发，
谁运营”的开发运维一体化方法。
4、智能端点与管道扁平化(Smartendpoints and dumb pipes)：
微服务架构主张将组件间通讯的相关业务逻辑/智能放在组件端点侧而非放在通讯组件中，通讯机制或组件应该尽量简单及松耦合。RESTful HTTP协议和仅提供消息路由功能的轻量级异步机制是微服务架构中最常用的通讯机制。
5、“去中心化”治理(DecentralizedGovernance)：
整体式应用往往倾向于采用单一技术平台，微服务架构则鼓励使用合适的工具完成各自的任务，每个微服务可以考虑选用最佳工具完成(如不同的编程语言)。
微服务的技术标准倾向于寻找其他开发者已成功验证解决类似问题的技术。
6、“去中心化”数据管理(DecentralizedData Management)：
微服务架构倡导采用多样性持久化(PolyglotPersistence)的方法，让每个微服务管理其自有数据库，并允许不同微服务采用不同的数据持久化技术。
7、基础设施自动化(InfrastructureAutomation)：云化及自动化部署等技术极大地降低了微服务构建、部署和运维的难度，通过应用持续集成和持续交付等方法有助于达到加速推出市场的目的。
8、故障处理设计(Designfor failure)：微服务架构所带来的一个后果是必须考虑每个服务的失败容错机制。因此，微服务非常重视建立架构及业务相关指标的实时监控和日志机制。
9、演进式的设计(EvolutionaryDesign)：微服务应用更注重快速更新，因此系统的计会随时间不断变化及演进。微服务的设计受业务功能的生命周期等因素影响。
如某应用是整体式应用，但逐渐朝微应用架构方向演进，整体式应用仍是核心，但新功能将使用应用所提供的API构建。
再如在某微服务应用中，可替代性模块化设计的基本原则，在实施后发现某两个微服务经常必须同时更新，则这很可能意味着应将其合并为一个微服务。
四、优点
1、复杂度可控：
将整体应用程序分解成一组服务，服务粒度按需可控，而每个服务是针对一个单一职责的业务能力的封装，专注做好一件事情。
2、独立开发和演化：
技术选型灵活，不受遗留系统技术约束。合适的业务问题选择合适的技术可以独立演化。服务与服务之间采取与语言无关的API进行集成。
开发人员可以自由选择任何有用的技术，可以独立的开发和演化所负责的服务，因为服务相对较小，使使用新技术重写服务变得可能。
3、独立部署：
每个微服务独立的部署。开发者不再需要协调其它服务部署对本服务的影响。这种改变可以加快部署速度。UI团队可以采用AB测试，快速的部署变化。微服务架构模式使得持续化部署成为可能。
4、独立按需扩展：
每个服务独立扩展。你可以根据每个服务的规模来部署满足需求的规模。甚至于，你可以使用更适合于服务资源需求的硬件。
比如，你可以在EC2 Compute Optimized instances上部署CPU敏感的服务，而在EC2 memory-optimized instances上部署内存数据库。
5、技术选型灵活：
微服务可通过最佳及最合适的不同的编程语言与工具进行开发，能够做到有的放矢地解决针对性问题。
6、容错及高可用：
通过负载均衡配置，可以实现微服务容错。
微服务架构方式是松耦合的，可以提供更高的灵活性。
微服务架构是持续交付(CD)的巨大推动力，允许在频繁发布不同服务的同时保持系统其他部分的可用性和稳定性。
五、缺点
1、运维开销及成本增加：
整体应用可能只需部署至一小片应用服务区集群，而微服务架构可能变成需要构建/测试/部署/运行数十个独立的服务，并可能需要支持多种语言和环境。这导致一个整体式系统如果由20个微服务组成，可能需要40~60个进程。
2、必须有坚实的DevOps开发运维一体化技能：
开发人员需要熟知运维与投产环境，开发人员也需要掌握必要的数据存储技术如NoSQL，具有较强DevOps技能的人员比较稀缺，会带来招聘人才方面的挑战。
3、隐式接口及接口匹配问题：
把系统分为多个协作组件后会产生新的接口，这意味着简单的交叉变化可能需要改变许多组件，并需协调一起发布。
在实际环境中，一个新品发布可能被迫同时发布大量服务，由于集成点的大量增加，微服务架构会有更高的发布风险。
4、代码重复：
某些底层功能需要被多个服务所用，为了避免将“同步耦合引入到系统中”，有时需要向不同服务添加一些代码，这就会导致代码重复。
5、分布式系统的复杂性：
作为一种分布式系统，微服务引入了复杂性和其他若干问题，例如跟踪问题困难、网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化、差异化的工作负载等，
开发人员需要考虑以上的分布式系统问题。
6、异步机制：
微服务往往使用异步编程、消息与并行机制，如果应用存在跨微服务的事务性处理，其实现机制会变得复杂化。
7、可测性的挑战：
在动态环境下服务间的交互会产生非常微妙的行为，难以可视化及全面测试。经典微服务往往不太重视测试，更多的是通过监控发现生产环境的异常，进而快速回滚或采取其他必要的行动。
但对于特别在意风险规避监管或投产环境错误会产生显著影响的场景下需要特别注意。
8、数量大管理复杂：
当服务数量增加，管理服务的复杂度大幅提升，需要合理、科学的建立服务的注册、发现、监控等机制。
六、微服务框架应具备的功能
1、API Gateway：
实现一个API网关作为所有客户端的唯一入口。API网关有两种方式来处理请求。有些请求被简单地代理/路由到合适的服务上，其他的请求被转给到一组服务
相比于提供普适的API，API网关根据不同的客户端开放不同的API。比如，Netflix API网关运行着客户端特定的适配器代码，会向客户端提供最适合其需求的API。
API网关也可以实现安全性，比如验证客户端是否被授权进行某请求。
2、负载均衡：
同时部署多套对等微服务和数据库，科学规划负载均衡算法，支持在API Gateway层对请求进行分发处理。
3、认证和鉴权：
支持统一认证和鉴权机制，通过管理和应用Token来实现认证和鉴权。
4、日志和审计：
框架一方面要记录重要的框架层日志、metrics和调用链数据，还要将日志、metrics等接口暴露出来，让业务层能根据需要记录业务日志数据。在运行环境中，所有日志数据一般集中落地到企业后台日志系统，做进一步分析和处理
5、统一错误处理：
对于框架层和服务的内部异常，如果框架层能够统一处理并记录日志，对服务监控和快速问题定位有很大帮助。
6、REST/RPC和序列化（通信方式）：
框架层要支持将业务逻辑以HTTP/REST或者RPC方式暴露出来，HTTP/REST是当前主流API暴露方式，在性能要求高的场合则可采用Binary/RPC方式。
针对当前多样化的设备类型(浏览器、普通PC、无线设备等)，框架层要支持可定制的序列化机制，例如，对浏览器，框架支持输出Ajax友好的JSON消息格式，而对无线设备上的Native App，框架支持输出性能高的Binary消息格式。
7、配置：
除了支持普通配置文件方式的配置，框架层还可集成动态运行时配置，能够在运行时针对不同环境动态调整服务的参数和配置。
8、安全处理封装：
安全和访问控制逻辑可以在框架层统一进行封装，可做成插件形式，具体业务服务根据需要加载相关安全插件。
9、消息总线：
轻量级的MQ或HTTP。
10、监控和告警：
主要是监控每个服务的状态，必要时产生告警
11、分布式管理(包括微服务和数据库)：
对微服务和数据库均支持分布式处理，微服务和数据库之间支持多对多组合应用。
12、微服务CI/CD流水线：
支持持续集成和持续部署，能够到DevOps一体化运维标准。
13、服务治理：
按需伸缩：部署与监控运维成本
独立部署：机器数量与部署成本
业务独立：服务依赖、治理，版本管理、事务处理
技术多样性：环境部署成本、约定成本
运行状态治理：监控、限流、SLA、LB、日志分析
部署：快速、复制、扩容；单机开发
调用：安全、容错、服务降级、调用延时
14、服务注册及发现：
提供服务注册及发现相应管理功能。
服务注册（客户端发现）：
提供统一服务注册中心，可以对所有服务进行跟踪及管理。
服务发现：
15、管理接口：
框架集成管理接口，一方面可以在线查看框架和服务内部状态，同时还可以动态调整内部状态，对调试、监控和管理能提供快速反馈。Spring Boot微框架的Actuator模块就是一个强大的管理接口。
16、限流和容错：
框架集成限流容错组件，能够在运行时自动限流和容错，保护服务，如果进一步和动态配置相结合，还可以实现动态限流和熔断。
17、事件调度机制：处理事件机制。
18、资源管理：
提供相关的资源管理功能。如：底层的虚拟机，物理机和网络管理。
19、统一代码框架：
提供统一框架，支持多种语言的运用。
20、统一服务构建和打包：
提供统一的管理机制对微服务进行构建和打包。使微服务的构建和打包标准化进行，也便于微服务间的交互。
21、统一服务测试：
提供统一的测试机制及工具，屏蔽服务内部的差异，可对微服务进行标准化测试。
22、服务依赖关系管理：
提供统一的管理机制及功能，采用科学、合理的管理策略来管理众多服务及相互依赖。例如分组、分层等。
23、统一问题跟踪调试框架，俗称调用链：
提供统一跟踪调试微服务的工具，可以方便的对调用链上的微服务进行跟踪和调试。
24、灰度发布：
支持产品发布的平滑演进，逐步扩大覆盖范围，通常也叫灰度放量。
25、蓝绿部署：
支持新旧版本的在线切换。
七、实践
具体参见: https://github.com/mqg007/CFCFrame