企业从单体架构往微服务架构设计难点探讨.doc

? ? ? ? ? ? ? ? 企业从单体架构往微服务架构设计难点探讨 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 当企业在面临诸如需求迭代频繁但是项目进度推进乏力、用户量高速增长但是系统出现瓶颈却没有好的解决方案，研发资源逐步增加但是团队协作效率却变的迟缓的情况，虽然使用微服务架构方案能解决所面临的问题，而且目前微服务架构的框架都比较成熟，例如Spring cloud或者dubbo在各大互联网平台都有成功案例，然而看似简单的框架在实际开发过程中会面临很多问题。 问题一：企业从单体架构往微服务架构转型怎么启动? 这个问题也是本次活动中大家比较关注的问题，追其根究主要是因为企业打算转型微服务，但是真正的实施后发现又很难，其实微服务架构转型不仅仅是一门技术活，更主要的的是组织结构和技术转型的结合，其中组织机构转型是起步的首要条件，包括统一思路和充分培训。(1)???? 思想统一当准备要实施微服务的时候首要条件就是获得高层的认可，因为涉及到组织结构的调整以及后续人力资源的增补，比如在单体应用中其组织机构包括开发部、测试部、运维部、DBA部，每个部门各司其职由高层统一指挥，看似很非常合理的组织结构，但是在项目或者迭代实际过程中会花费大量的时间去跨部门沟通，形成了孤岛式功能团队。 但是在实施微服务的时候，希望能协同配合快速交付，如果还是需要多次跨部门协调处理问题的话，那么“微”很难实现“微”的好处，微服务的团队应该是如下所示，所以如果没有高层参与那么组织架构就不会调整。 (2)???? 充分培训微服务开发关注点：微服务架构的开发人员具备“精”、“气”、“神”的特质，否则在后续发展阶段一定会出现各种难题。“精”是指熟悉业务，熟悉选型的开发框架，“气”是指大家的思想认知一致，能够在一个频道上对话，“神”是指需要了解其理论知识，明白为什么需要这样而不是那样。微服务在开发设计过程中需要关注以下点： 一份基准代码多份部署（deploy）：程序部署需要做到和环境无关，不需要改动任何一行代码，如图2-3 显式声明依赖关系:通过依赖清单 ，确切地声明所有依赖项（例如MAVEN 依赖），新进开发者简化了环境配置流程“做产品”而不是“做项目” 在环境中存储配置:所要求的代码和配置严格分离，配置可以完全不一样，但是代码必须是一样的，配置和代码无关“去中心化”地治理技术 把后端服务当作资源:后端服务是指程序运行所需要的通过网络调用的各种服务如数据库，MQ，缓存等。例如在不进行任何代码改动的情况下，将MySQL 数据库换成第三方服务 严格分离构建和运行：构建阶段是指将代码仓库转化为可执行包的过程，发布阶段会将构建的结果和当前部署所需配置相结合，并能够立刻在运行环境中投入使用，如回滚，运行阶段是指针对选定的发布版本，在执行环境中启动一系列应用程序进程 无状态进程运行应用：运行环境中，应用程序通常是以一个和多个 进程 运行的，任何需要持久化的数据都要存储在 后端服务内，比如数据库 问题二：微服务中所谓的服务到底如何拆分，服务拆分到什么粒度算好的服务？ 在谈服务拆分之前首先给服务做个定义：服务是分布式架构下的基础单元，包含了一组特定的功能。微服务拆分的方式没有明确标准，可谓说是千人千面，每个人对于服务拆分理解程度和拆分尺度都不一样，有的团队按每个接口一个服务。一般来说我们在拆分的时候会结合理论知识和拆分原则来综合考虑： 1)?? 微服务拆的理论指导 - 团队规模大小一般来说5-7个人一个小组比较合适，因为沟通效率和团队可扩展性都能得到保障。如果一个团队人数过少的话，本来应该是多人开发的服务最有由1-2人来开发，会导致本来设计好的服务拆分逻辑最后却都合并在一个工程上做开发了，失去了微服务的意义。 - 项目交付周期尽可能缩短项目交付周期短，把频繁需求变更的功能尽量独立成单独的服务，保证快速的迭代，还能满足快速上线的需求，缩短了项目交付周期，同时还能做到随时回滚，风险变小，从而提高系统稳定性。 变更影响范围一个业务迭代功能点，尽量不要分布到多个微服务中，尽量将关联的实体对象存于一个微服务，避免分布式事务，比如把20%经常变动的部分进行抽离，80%不经常变动的单独部署和管理。 - 吞吐量大小频繁访问，吞吐量大的服务，尽量独立微服务，方便扩容, 能够有效地提高资源利用率。 2)?? 服务拆分原则 - 高内聚低耦合高内聚低耦合是软件工程中的概念，在软件设计中通常用耦合度和内聚度作为衡量模块独立程度的标准。但是在微服务拆分中同样试用，服务拆分的一个准则是高内聚低耦合。从功能粒度来看，高内聚即每个服务尽可能只完成一件事（最大限度的聚合）； 低耦合即减少外部服务依赖，尽量避免服务再调用服务。从数据库角度来看每个服务单独试用