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