当前位置 博文首页 > lex-wu：微服务架构 - 正确的开始
微服务自从Fred George提出，后续逐渐由不同的大师如Martin Fowler，Neal Ford等人接力推广演进后，已经在业界如火如荼的流行了好些年，它的目的是有效的拆分应用，实现敏捷开发和部署 。
借用Martin Fowler的话说：
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。
每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相协作（通常是基于HTTP协议的RESTful API）。
每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。
从这里面我们可以看出，这里面的关键字是“小”，“独立”，“轻量级”，从中我们可以总结为：服务之间是松耦合的，不相互影响的。但“小”绝对不是字面上理解的小，我们下面将介绍一个服务的小的维度是什么。
提到微服务，就不能不提到单体应用了，我们通常所说的单体应用，即将所有功能都打包成在一个独立单元的应用程序。
一个典型的单体应用就是将所有业务场景的表示层、业务逻辑层和数据访问层放在一个工程中，最终经过编译、打包，部署在一台服务器上。
在微服务或者SOA架构没提出来之前，业界应该基本都是单体应用，分布式系统架构在业界内已经有较长的历史了，但单体应用还是占据着大半壁江山。
存在即合理的
所以存在的东西都具备自己的优点，我们来看一下单体应用的优点。
这些优点是显著的，它们能给人带来明确的掌控感觉，而不是不可控的飘渺虚无感。
然而，它的缺点也是非常明显的，想想我们现在大部分的项目，伴随着越来越快的互联网信息时代，业务要的就是灵活变动和快速上线，针对于灵活和快速，单体应用是无法提供的。
可以肯定的是，一旦你的应用变成一个又大又复杂的怪物，那开发团队肯定很痛苦。敏捷开发和部署举步维艰，每次的开发都会引出其他问题，因为它们的耦合性太强了。
其中最主要问题就是这个应用太复杂，以至于任何单个开发者都不可能搞懂它。因此，修正bug和正确的添加新功能变的非常困难，并且很耗时。
另外，团队士气也会走下坡路。如果代码难于理解，就不可能被正确的修改，最终会走向巨大的、不可理解的泥潭。
所以在这时，很多人把目光投向了微服务。
首先任何的技术不会平白无故的出现，它们的出现，是某些痛点一直在困扰着大多数人，所以这些技术的出现，都是有特定背景的。
从上面来看，有诉求才会有发展，没有单体式应用的痛点折磨，没有分布式系统的铺垫，没有自动化工具的应用，是不可能出现所谓的微服务的，所以我们可以说，微服务架构是演进过来的。
微服务在Chris口中，是一种架构设计风格，而在国内，更多的开发者视之为具体的某个服务，所以我们通常的说法是“一个微服务”，按照Chris自己的说法，系统是采用了微服务架构设计风格，由若干个服务构成，这才是一个完整的微服务。
微服务这个术语让我们很多人错误的将关注点聚焦在“微”上，它暗示着我们服务的颗粒度是应该非常小的。
实际上，大小不是一个重要的考虑因素。
细想一下微服务的进化铺垫，我们为什么要拆服务？是由于单体应用的臃肿庞大且耦合性过高的特性。所以我们在拆分的过程中，更多的考虑方面是在如何避免单体应用的耦合问题，不然拆出来的一样是一个相互牵扯的单体微应用，所以我们的关注点应该是在每个服务的松散耦合上，确定好它的边界，让每个服务能做到真正的松耦合，而不仅仅是大小问题。
诚然，小服务确实是维护性更高。但我们微服务的目标，更多的是定义我们的工作方式，比如定义为可由小团队自主开发，并且交付时间短，与其他团队协作少，不会相互影响的工作方式。
所以我们服务的设计和定义，需遵循我们的目标法则去规划的，而这个法则就是服务内的高内聚和服务间的低耦合。
微服务架构通过把一些小的，松耦合的服务组织在一起，重新定义了我们的应用，这样的结果是提升了我们开发阶段的效率，特别是可维护性，可测试性和可部署性，通过这样的方式影响着团队的效率提升。
每个构成微服务架构体系的服务，本质都是一个可独立运行的应用程序。
这个服务是由一组边界清晰，高内聚的职责组成，而且它可以做自己的负载均衡，独立部署，独立发布，能够快速脱离单体应用的局限性快速上线。
这也是微服务的优势所在，只要做到接口兼容或者版本兼容，不必做过多的服务依赖。
微服务的优点众多，但我认为它最重要的是改变着我们的工作方式，如：
我们知道，敏捷开发这种软件工程方法已经在很多公司中采用了，敏捷开发的意义在于更快速的交付可运行版本以及迭代做功能最小闭环，它是这个信息时代的必然产物。当我们采用微服务时，在团队自治的同时，意味着更快速的开发和交付。
敏捷开发带来的不仅仅是开发模式上的改变，也带来了组织结构的变化，衍生出更多的小团队自治，小团队实施敏捷开发，带来更快的功能迭代和独立发布，即使出现问题也不会影响整个应用。
在Neal Ford的微服务理念中，Microservices are the first post DevOps revolution architecture，DevOps所涵盖的一系列文化和理念，是微服务演进过程中必不可少的先决条件。
微服务的流行，更好的推动了Devops文化，它们是相辅相成的。
比较确定的说，在传统的运维模式下，是很难有效实现微服务架构的，因为微服务在治理层面需要自动化基础设施、自动化部署、自动化验证、以及利用有效的工具完成运维、监控、告警等。而只有将DevOps与微服务紧密的结合起来，才能达到事半功倍的效果。
当我们采用单体服务时，它所使用的编程语言就已经确定了，但微服务支持使用不同的语言开发，允许你选择合适的技术栈。
我们的企业发展能存活的根本是什么？就是能赚钱才能活下去，换言之也就是对成本的控制。当我们能够采用适合自己的成本投入方式，在各个环节和服务采用最合适的技术栈，能够给企业的投入成本做一定的保障。
组织结构变化会给我们带来什么好处？
其实我们一直在暗示着，服务的职责要单一，做到专，然而这个专并不仅仅在服务的职责层面上，还有在组织结构上， 微服务势必会影响到我们的中台战略能力，所以我们更需要不同的组专注于不同的技术和业务。
简单点说，让专业的人做专业的事！这样才能更好的提高整体的生产效率，而不是事事都有牵绊。
这个似乎并不是优点，但我相信对很多人来说，这又确切是个优点，因为这些技术对所有有技术抱负的人来说，造就了一个很好的时代。
当我们采用微服务时，目光已经不能仅局限于应用层面的开发了，容器化，服务编排工具，服务网格，云原生等新生的技术，让我们知道如何更好的治理好自己的服务群，支撑自己的服务更好的扩展。
这些挑战，分析一下本质，就是对人的要求更高了，所以说采用微服务并不仅仅是技术层面带来的冲击，更多的是对人带来的思想/能力冲击。
在实践微服务的过程中，可以划分为三部曲：
这三部也是涵盖了微服务架构落地的全部步骤，每一步都会有不同的指导方法论用于区别于传统的开发思想，后续将会基于这些步骤结合流行的方法学来指导我们服务落地。
微服务不是银弹！
我特别喜欢说的一句话是：任何的技术，都是有适用场景的。所以我很喜欢看到那些能基于目前的痛点以及中长期的发展所面临的问题分析， 对比单体架构和微服务架构带来的收益比。
我们需要的是思考技术能带来的价值，而不是为技术疯狂。
任何的技术手段，都是用来服务业务的，能支撑业务创造价值的，才是好技术，否则这些技术一文不值。
不管黑猫白猫，捉到老鼠的就是好猫！
微服务架构也不例外。
所以当你想要采用微服务时，问一下自己这些问题：
当你能做到对以上问题都有清晰答案后，且仍然决定采用微服务架构，说明你已经对微服务所带来的收益比有了自己的判断。
在将组织推向微服务道路之前，最重要的决策人理解了“为什么是微服务”，而不是“为什么不是微服务”。
