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