微服务架构 - 正确的开始

　　前言

　　微服务自从Fred George提出，后续逐渐由不一样的大师如Martin Fowler，Neal Ford等人接力推广演进后，已经在业界如火如荼的流行了好些年，它的目的是有效的拆分应用，实现敏捷开发和部署 。

　　借用Martin Fowler的话说：

　　微服务架构是一种架构模式，它提倡将单一应用程序划分红一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。

　　每一个服务运行在其独立的进程中，服务与服务间采用轻量级的通讯机制互相协做（一般是基于HTTP协议的RESTful API）。

　　每一个服务都围绕着具体业务进行构建，而且可以被独立的部署到生产环境、类生产环境等。

　　从这里面咱们能够看出，这里面的关键字是“小”，“独立”，“轻量级”，从中咱们能够总结为：服务之间是松耦合的，不相互影响的。但“小”绝对不是字面上理解的小，咱们下面将介绍一个服务的小的维度是什么。

　　单体服务　　

　　提到微服务，就不能不提到单体应用了，咱们一般所说的单体应用，即将全部功能都打包成在一个独立单元的应用程序。

　　一个典型的单体应用就是将全部业务场景的表示层、业务逻辑层和数据访问层放在一个工程中，最终通过编译、打包，部署在一台服务器上。

 　　在微服务或者SOA架构没提出来以前，业界应该基本都是单体应用，分布式系统架构在业界内已经有较长的历史了，但单体应用仍是占据着大半壁江山。

　　存在即合理的

　　因此存在的东西都具有本身的优势，咱们来看一下单体应用的优势。

　　优势

• 开发方便：集中式管理，只须要在一个解决方案中编程和构建
• 测试相对简单：只须要写一些端到端的测试用例，启动便可总体联调查找问题
• 部署手段简易：只须要把一份构建好的文件丢上服务器
• 容易横向扩展：能够部署多个实例，由负载均衡器调度便可
• 没有分布式的管理/调用开销

　　这些优势是显著的，它们能给人带来明确的掌控感受，而不是不可控的飘渺虚无感。

　　然而，它的缺点也是很是明显的，想一想咱们如今大部分的项目，伴随着愈来愈快的互联网信息时代，业务要的就是灵活变更和快速上线，针对于灵活和快速，单体应用是没法提供的。

　　缺点

• 开发效率低：系统庞大复杂，没人能理解所有，且全部的开发在一个项目改代码，代码冲突不断
• 代码维护难：代码功能耦合在一块儿，牵一发动全身
• 部署不灵活：构建时间长，任何小修改必须从新构建整个项目，这个周期每每很长
• 稳定性不高：系统缺少故障隔离，一个微不足道的小问题，能够致使整个应用挂掉 

　　能够确定的是，一旦你的应用变成一个又大又复杂的怪物，那开发团队确定很痛苦。敏捷开发和部署举步维艰，每次的开发都会引出其余问题，由于它们的耦合性太强了。

　　其中最主要问题就是这个应用太复杂，以致于任何单个开发者都不可能搞懂它。所以，修正bug和正确的添加新功能变的很是困难，而且很耗时。

　　另外，团队士气也会走下坡路。若是代码难于理解，就不可能被正确的修改，最终会走向巨大的、不可理解的泥潭。

　　因此在这时，不少人把目光投向了微服务。

　　微服务　　

　　由来

　　首先任何的技术不会无缘无故的出现，它们的出现，是某些痛点一直在困扰着大多数人，因此这些技术的出现，都是有特定背景的。

　　从上面来看，有诉求才会有发展，没有单体式应用的痛点折磨，没有分布式系统的铺垫，没有自动化工具的应用，是不可能出现所谓的微服务的，因此咱们能够说，微服务架构是演进过来的。

　　微服务是一种架构风格

　　微服务在Chris口中，是一种架构设计风格，而在国内，更多的开发者视之为具体的某个服务，因此咱们一般的说法是“一个微服务”，按照Chris本身的说法，系统是采用了微服务架构设计风格，由若干个服务构成，这才是一个完整的微服务。

　　“微”服务

　　微服务这个术语让咱们不少人错误的将关注点聚焦在“微”上，它暗示着咱们服务的颗粒度是应该很是小的。

　　实际上，大小不是一个重要的考虑因素。

　　细想一下微服务的进化铺垫，咱们为何要拆服务？是因为单体应用的臃肿庞大且耦合性太高的特性。因此咱们在拆分的过程当中，更多的考虑方面是在如何避免单体应用的耦合问题，否则拆出来的同样是一个相互牵扯的单体微应用，因此咱们的关注点应该是在每一个服务的松散耦合上，肯定好它的边界，让每一个服务能作到真正的松耦合，而不只仅是大小问题。

　　诚然，小服务确实是维护性更高。但咱们微服务的目标，更多的是定义咱们的工做方式，好比定义为可由小团队自主开发，而且交付时间短，与其余团队协做少，不会相互影响的工做方式。

　　因此咱们服务的设计和定义，需遵循咱们的目标法则去规划的，而这个法则就是服务内的高内聚和服务间的低耦合。

　　微服务架构经过把一些小的，松耦合的服务组织在一块儿，从新定义了咱们的应用，这样的结果是提高了咱们开发阶段的效率，特别是可维护性，可测试性和可部署性，经过这样的方式影响着团队的效率提高。

 　　服务的本质

　　每一个构成微服务架构体系的服务，本质都是一个可独立运行的应用程序。

　　这个服务是由一组边界清晰，高内聚的职责组成，并且它能够作本身的负载均衡，独立部署，独立发布，可以快速脱离单体应用的局限性快速上线。

　　这也是微服务的优点所在，只要作到接口兼容或者版本兼容，没必要作过多的服务依赖。  

　　优势

　　微服务的优势众多，但我认为它最重要的是改变着咱们的工做方式，如：

• 更加契合敏捷开发

　　咱们知道，敏捷开发这种软件工程方法已经在不少公司中采用了，敏捷开发的意义在于更快速的交付可运行版本以及迭代作功能最小闭环，它是这个信息时代的必然产物。当咱们采用微服务时，在团队自治的同时，意味着更快速的开发和交付。

　　敏捷开发带来的不只仅是开发模式上的改变，也带来了组织结构的变化，衍生出更多的小团队自治，小团队实施敏捷开发，带来更快的功能迭代和独立发布，即便出现问题也不会影响整个应用。

• Devops文化的推广

　　在Neal Ford的微服务理念中，Microservices are the first post DevOps revolution architecture，DevOps所涵盖的一系列文化和理念，是微服务演进过程当中必不可少的先决条件。

　　微服务的流行，更好的推进了Devops文化，它们是相辅相成的。　　

　　比较肯定的说，在传统的运维模式下，是很难有效实现微服务架构的，由于微服务在治理层面须要自动化基础设施、自动化部署、自动化验证、以及利用有效的工具完成运维、监控、告警等。而只有将DevOps与微服务紧密的结合起来，才能达到事半功倍的效果。

• 技术栈的选择

　　当咱们采用单体服务时，它所使用的编程语言就已经肯定了，但微服务支持使用不一样的语言开发，容许你选择合适的技术栈。

　　咱们的企业发展能存活的根本是什么？就是能赚钱才能活下去，换言之也就是对成本的控制。当咱们可以采用适合本身的成本投入方式，在各个环节和服务采用最合适的技术栈，可以给企业的投入成本作必定的保障。 

• 组织结构的变化

　　组织结构变化会给咱们带来什么好处？

　　其实咱们一直在暗示着，服务的职责要单一，作到专，然而这个专并不只仅在服务的职责层面上，还有在组织结构上， 微服务势必会影响到咱们的中台战略能力，因此咱们更须要不一样的组专一于不一样的技术和业务。

　　简单点说，让专业的人作专业的事！这样才能更好的提升总体的生产效率，而不是事事都有牵绊。

• 云生态下的新技术冲击

　　这个彷佛并非优势，但我相信对不少人来讲，这又确切是个优势，由于这些技术对全部有技术抱负的人来讲，造就了一个很好的时代。　　

　　当咱们采用微服务时，目光已经不能仅局限于应用层面的开发了，容器化，服务编排工具，服务网格，云原生等新生的技术，让咱们知道如何更好的治理好本身的服务群，支撑本身的服务更好的扩展。　　

 　　挑战

• 　微服务本质上是分布式系统，因此在分布式系统中遇到的难点，在微服务中都会遇到，分布式系统进程间的通讯保证，网络开销以及事务处理历来都是难题
• 　微服务的流行，离不开容器化和云生态，离不开gRPC，ServiceMesh，云原生等新技术的崛起以及实际生产应用。换言之，你须要了解乃至熟知这些技术，毕竟传统的单体应用只须要更多的专一于应用层面
• 　微服务架构带来过多的运维操做，须要团队具有必定的 DevOps 技能，在运维层面开销会很大
•    治理中心（包括基础设施架构，集合着CICD，监控等微服务必要的非功能性需求）
•    测试将会是很是难，由于它再也不是端到端，还很大可能会存在多版本的不一样服务带来不一样的测试场景

　　这些挑战，分析一下本质，就是对人的要求更高了，因此说采用微服务并不只仅是技术层面带来的冲击，更多的是对人带来的思想/能力冲击。

　　微服务的解剖

　　在实践微服务的过程当中，能够划分为三部曲：

1. 服务划分
2. 服务开发
3. 服务治理

　　这三部也是涵盖了微服务架构落地的所有步骤，每一步都会有不一样的指导方法论用于区别于传统的开发思想，后续将会基于这些步骤结合流行的方法学来指导咱们服务落地。

　　总结

　　微服务不是银弹！ 

　　我特别喜欢说的一句话是：任何的技术，都是有适用场景的。因此我很喜欢看到那些能基于目前的痛点以及中长期的发展所面临的问题分析， 对比单体架构和微服务架构带来的收益比。

　　咱们须要的是思考技术能带来的价值，而不是为技术疯狂。

　　任何的技术手段，都是用来服务业务的，能支撑业务创造价值的，才是好技术，不然这些技术一文不值。

　　无论黑猫白猫，捉到老鼠的就是好猫！　　

　　微服务架构也不例外。

　　因此当你想要采用微服务时，问一下本身这些问题：

• 为何团队想要采用微服务？采用后团队将能获得什么？（说明充分了解了单体/微服务的优缺点，并能清晰了解到业务以及团队在中长期所面临的问题点）
• 是否组织结构以及文化底蕴有必定的支撑？（团队是否能经得起微服务所带来的冲击）
• 是否有必定的技术基础支撑？（说明能对微服务的所面临的技术挑战有了必定的认识）　

　　当你能作到对以上问题都有清晰答案后，且仍然决定采用微服务架构，说明你已经对微服务所带来的收益比有了本身的判断。　

　　Last but not least

　　在将组织推向微服务道路以前，最重要的决策人理解了“为何是微服务”，而不是“为何不是微服务”。