《开展基于微服务架构进行系统开发的设想(共5页).doc》由会员分享，可在线阅读，更多相关《开展基于微服务架构进行系统开发的设想(共5页).doc（5页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、精选优质文档-倾情为你奉上开展基于微服务架构进行系统开发的设想一、对微服务架构的理解1、微服务架构的概念从Martin Fowler提出的微服务的概念来看，大概可以从以下几点标准来理解： 分布式服务组成的系统 按照业务而不是技术来划分提供的功能 做有生命的产品而不是项目 强调服务个体，弱化互相之间的通信 自动化运维（DevOps） 容错 快速演化 总的来说，微服务的目的是有效的拆分应用，实现敏捷开发和部署 。2、微服务的优势和不足 微服务的思路是把单一的巨大应用拆分为众多松散耦合的微小服务，其通常是按照业务功能来分解的，每一个服务虽然微小但却实现相对完整的功能，使用私有的数据库，可以单独构建和
2、部署，某个服务的修改和部署不会影响其他正在运行的服务，提供语言无关的 API 接口供其他模块调用。这种风格与传统的面向服务架构 SOA比较相似，经过多年的发展，SOAP、Web Services、ESB等技术出现使 SOA 得以实现，众多厂商也制定了相关的标准. 两者最重要的区别在于 SOA 使用复杂的 ESB 集成为单一应用，而微服务是轻量级的，不使用复杂的 ESB，松散耦合，可以独立部署。 微服务架构在规模较大的应用中具有明显优势。首先体现在独立性方面，服务是松散耦合的，有明确的系统边界，各开发人员可以并行开发和部署，避免了牵一发而动全身，提高了效率。其次是技术选择灵活，可针对具体业务特性
3、和团队技能为一个服务选择最合适的语言、框架和数据库，各服务使用不同的技术，技术转型的成本也大为降低。再次是系统伸缩更自由，可针对某些服务单独进行伸缩，实现系统三维度伸缩。最后是服务可独立部署，借助自动化构建和部署工具，为DevOps的实施提供更好的支持。 当然，微服务的优势也是有代价的。第一显而易见的是性能问题，微服务应用中每个服务运行在独立进程中，服务间的调用需要通过网络传输，当众多服务需要相互调用时，就要考虑网络延迟对系统性能的影响，一般来讲通常的应用（包含若干个微服务），系统响应时间差距不远，但当应用包含成百上千的服务时，远程调用的性能损耗是一个要解决的关键问题。 第二，微服务本质上就是
4、一个分布式应用，分布式系统固有的可靠性等问题随着微服务数量的增加变得越来越突出。第三个也属于分布式系统的问题，如何保证数据一致性，微服务使用非集中式的数据管理，要解决数据一致性问题比起单体式应用要困难得多。故而在运用微服务架构的实践中，主要面临的就是服务间通信，服务发现和服务部署 3 个关键问题。二、项目开发实施的现状公司目前的产品线比较丰富，但每个业务系统相对来说比较独立，对产品的规范开发、统一管理稍显不足，从而导致项目实施的周期较长，实施过程中需要解决的问题也较多，人力资源的成本不能较好的控制。1. 目前系统实施的模式：工程师进场调研 分析业务功能的差异部分，进行记录和确认，编写调研/需求
5、报告组织人员进行二次开发与用户进行系统功能确认进行原始数据的初始化，编写操作手册，组织培训与推广试用验收2. 定制化开发与服务是公司项目实施的最大特点，每个业务系统大都是在公司原有产品的基础上，由项目组成员按照学校的各项业务规则进行定制化开发与设计。这样做的好处是开发出来的系统能完成贴合用户单位的实际需求，能最大限度地保证业务在后期能较好的得到推广与应用，不足的地方则在于公司的产品因为不同学校间管理规则与制度的不一致，使得实现的功能不尽相同。3. 各个项目现场实现的业务功能、技术成果无法实现高效地沟通和分享，项目的可移植性、可复用性不高，而各个学校的管理模式个性化较强，各个业务系统管理范围又比
6、较广，从而导致每个项目类似业务功能无法实现高效率的整合与实施，降低了项目实施效率。4. 目前公司缺乏一个比较成熟、完善、高效的的数据中心，各类业务数据的互连互通也没有形成具有特色的产品化体系，业务系统在运行的过程中有较大部分的时间和资源开销在数据的频繁交互上。三、下一步开展基于微服务架构进行系统开发的设想基于对微服务架构的理解，及公司目前在项目开发、实施的现状，公司可以从以下几个方面开始尝试，将现有开发模式逐步向微服务架构模式转变：1、对公司现有产品、系统进行分析、评估，尽快梳理出各个业务模块的标准服务流程。在梳理的过程中，既可以对公司现有产品、系统进行必要的调整与规范，又能将每一个业务模块中
7、最小服务单元整理出来。2、为了在业务架构变更的过程中不影响现有系统的开发与实施，并保证系统架构的可回溯性，当有新的业务需求过来时，如果可以独立开发为一个服务，就单独开发，然后为老服务和新服务直接编写胶水代码（Glue Code）这个过程不容易，但这是分解原有业务服务必要的第一步。3、详细分类识别单体型应用中的可以分离出来当做单独服务的业务模块。拟分离出来的业务模块可从具有如下特点的模块中考虑：两个模块对资源的需求是冲突的（一个是CPU密集型、一个是IO密集型）；授权鉴定层也适合单独分离出一个服务。每分离出一个服务，就需要编写对应的胶水代码来与剩下的服务通信，这样，在逐渐演进过程中，就分部完成了整个系统的架构更新。4、对支撑平台（如：数据中心、统一身份认证、信息门户、办事服务大厅等）进一步优化，整合各个用户单位有共性的功能点，优化平台技术结构，更好地位基于微服务架构下的其它各类子应用。专心-专注-专业