5 微服务公司转型微服务，真的有必要吗？.docxVIP

【微服务】公司转型微服务，真的有必要吗？ 2020-05-03 原文 来源：谦镒?架构师技术联盟  在，在互联网圈子里，不晓得何时微服务这个概念已经深化到了我们圈内的各个角落，好像假如不赶上这个潮流，公司的产品就将被淘汰了。 这个专场开场时，老师给我们说了个他的一段经受。 一天他邻居问他：“你的微服务课程我可以去听么？”老师很是惊异，说：“你做微商的怎样这么好学呀，你晓得啥是微服务么？”邻居说：“微服务不是为微商服务的么？” 当然这略带有点喜剧性了，不过对于微服务，真的是和我们理解的那样么？我在听这场共享之前我一直认为，微服务不就是把业务依据功能模块切割，让他独立出来么？ 听完这场共享，对微服务的定义，有了全新的生疏。 1、微服务不是简约的模块切割 目前业内对微服务存在的误会有很多，这里ThoughtWorks的架构师和坚老师给我们列出来几点： 构建HTTP服务，有用Docker容器运转它，并且用Kubernets做集群管理，就是微服务 使用API Gateway和服务发觉以及服务registry，这就是微服务 使用Spring Boot框架构建http服务，并使用Netflix OSS，这就是微服务 使用Azure Service Fabric 构建并且运转使用程序，这就是微服务 构建轻量级的RESTful API，这就是微服务 有很多框架声称是微服务框架。使用这些框架的任意一种来构建使用程序，这就是微服务 看完这些，我就有点蒙圈了，那到底怎样的才算微服务呢？下面是老师对微服务的一个概括： 微服务架构是一种架构模式，它提倡将单一使用程序划分成一组小的服务，每个服务运转在其独立的进程中，服务间接受轻量级的通信机制相互沟通(通常是基于HTTP协议的RESTful API)。每个服务都围围着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。 同时和坚老师给我们共享了微服务具有以下几点特点： 通过服务进行组件化 围绕业务力量组织 做产品而不是做项目 只能端点与傻瓜管道 去中心化地管理技术 去中心化地管理数据 基础设备自动化 容错设计 演进式设计 我这里的理解是微服务其实是围绕业务力量组织进行划分的一整套服务集群，但是该怎样划分呢？他的粒度是什么呢？ 2、别一不当心把微服务切成了小的单体 假设有一天你的系统已经进行了“微服务”改造，由于你的业务进展，新的需求如潮水般涌来，渐渐的发觉某些“微服务”开头渐渐的膨胀起来。 发觉膨胀的“微服务”有一部分业务又需要拆分了，而且这个服务内部还高度耦合，这不就又变成了，拆分之前的服务了么？ 你拆分成的不是微服务，而是一个小的单体。 关于怎样拆分微服务，和坚老师给我推举了一个叫DDD服务设计的思想： 要求我们从业务视角去分别简单度，最终目标都是为最求高响应力。 让业务架构和系统架构构成绑定关系，从而当我们去响应业务变化调整业务架构时，系统架构的转变是随之而发的。 虽然短短的两句话，但是要理解做好，真不是那么简约，还待深化学习。 目前微服务只存在一个概念性的阶段，要想将我们现有的服务切分成微服务，依据什么标准进行切分，不同的行业，不同的业务场景，将是不同的，这是一个难题？ 当我们辛辛苦苦的把业务切成了一个一个小的服务在跑时，假如哪天业务进展，发觉这两个服务还是和在一起跑比较好，这时，你将面临的不是单单的把两个代码合在一起这么简约。 代码上的冲突，修改上下游的依靠，部署架构都将是一个挑战。微服务的合并，比拆分更难。 3、一个完整的微服务离不开完善的自动化运维 当我们的项目被拆分成了微服务在线上跑了，我们的开发看到的将不再是一整个业务的代码，而是一个一个小的模块服务。 我们的开发将面临：我们得把全体的全部服务了解个遍，或者相关的服务模块了解完。 假如不能了解完，将会消灭：在版本迭代时，我们修改的代码，能保证这个服务上没问题，不能保证上线后对其他的业务不会有影响。 对于这个问题，微软的MVP陈锋逸老师提出了一个建议，借助一些代码即架构的工具来弥补这块。 微服务落地，我们还将面临，我们的服务散落在各个地方，运维的同事将怎样进行监控，怎样晓得此时此刻哪个服务挂了，哪个服务超载了，超载时我们怎样进行扩容，这都是我们要处理的问题。 还有，假如我们辛辛苦苦做成了微服务，在版本发布时，怎样保证线上全部容器的版本一直性，也是要处理的问题。 这一系列的问题就涉及到可持续性交付这块了，从开发提交代码，到测试，到构建，再到测试用例的掩盖，最终到生产这一连贯的工作，怎样让他们自动化？假如做不到自动化，那投入的成本将可能是传统的架构的N倍。 4、结束语 我不是一个架构师，只是一个小小的开发者，全部行文都是依据一个开发者的角度结合今日老师讲的所写，所以可能有诸多不恰当的措词，欢迎指正。 原文链接： /vi