相亲网站策划书,网站建设中html模板,自学考试,自己建设网站需要服务器2019独角兽企业重金招聘Python工程师标准 1. 背景与挑战 随着公司国际化战略的推行以及本土业务的高速发展#xff0c;后台支撑系统已经不堪重负。在吞吐量、稳定性以及可扩展性上都无法满足日益增长的业务需求。对于每10万元额度的合同#xff0c;从销售团队… 2019独角兽企业重金招聘Python工程师标准 1. 背景与挑战 随着公司国际化战略的推行以及本土业务的高速发展后台支撑系统已经不堪重负。在吞吐量、稳定性以及可扩展性上都无法满足日益增长的业务需求。对于每10万元额度的合同从销售团队准备材料、与客户签单、递交给合同部门再到合同生效大概需要3.5人天。随着业务量的快速增长签订合同的成本急剧增加。 合同管理系统是后台支撑系统中重要的一部分。当前的合同系统是5年前使用.NET基于SAGE CRM二次开发的产品。 一方面系统架构过于陈旧性能、可靠性无法满足现有的需求。另一方面功能繁杂结构混乱定制的代码与SAGE CRM系统耦合度极高。由于是遗留系统熟悉该代码的人早已离职多时新团队对其望而却步只能做些周边的修补工作。同时还要承担着边补测试边整理逻辑的工作。 在无法中断业务处理的情况下为了解决当前面临的问题团队制定了如下的策略 1). 在现有合同管理系统的外围构建功能服务接口将系统核心的功能分离出来。 2). 利用这些功能服务接口作为代理解耦原合同系统与其调用者之间的依赖 3). 通过不断构建功能服务接口逐渐将原有系统分解成多个独立的服务。 4). 摒弃原有的合同管理系统使用全新构建的(微)服务接口替代。 2. 什么是微服务 多年来我们一直在技术的浪潮中不断乘风破浪扬帆奋进寻找更好的方式构建IT系统。微服务架构(Micro Service Architect)是近一段时间在软件体系架构领域里出现的一个新名词。它通过将功能分解到多个独立的服务以实现对解决方案或者复杂系统的解耦。 微服务的诞生并非偶然: 领域驱动设计指导我们如何分析并模型化复杂的业务敏捷方法论帮助我们消除浪费快速反馈持续交付促使我们构建更快、更可靠、更频繁的软件部署和交付能力虚拟化和基础设施自动化( Infrastructure As Code)则帮助我们简化环境的创建、安装DevOps文化的流行以及特性团队的出现使得小团队更加全功能化。这些都是推动微服务诞生的重要因素。 实际上微服务本身并没有一个严格的定义。不过从业界的讨论来看微服务通常有如下几个特征: 小且专注于做一件事情 每个服务都是很小的应用至于有多小是一个非常有趣的话题。有人喜欢100行以内有人赞成1000行以内。数字并不是最重要的。仁者见仁智者见智只要团队觉得合适就好。只关注一个业务功能这一点和我们平常谈论的面向对象原则中的”单一职责原则”类似每个服务只做一件事情并且把它做好。 运行在独立的进程中 每个服务都运行在一个独立的操作系统进程中这意味着不同的服务能被部署到不同的主机上。 轻量级的通信机制 服务和服务之间通过轻量级的机制实现彼此间的通信。所谓轻量级通信机制通常指基于语言无关、平台无关的这类协议例如XML、JSON而不是传统我们熟知的Java RMI或者.Net Remoting等。 松耦合 不需要改变依赖只更改当前服务本身就可以独立部署。这意味着该服务和其他服务之间在部署和运行上呈现相互独立的状态。 综上所述微服务架构采用多个服务间互相协作的方式构建传统应用。每个服务独立运行在不同的进程中服务与服务之间通过轻量的通讯机制交互并且每个服务可以通过自动化部署方式独立部署。 3.微服务的优势 相比传统的单块架构系统(monolithic)微服务在如下诸多方面有着显著的优势 异构性 问题有其具体性解决方案也应有其针对性。用最适合的技术方案去解决具体的问题往往会事半功倍。传统的单块架构系统倾向采用统一的技术平台或方案来解决所有问题。而微服务的异构性可以针对不同的业务特征选择不同的技术方案有针对性的解决具体的业务问题。 对于单块架构的系统初始的技术选型严重限制将来采用不同语言或框架的能力。如果想尝试新的编程语言或者框架没有完备的功能测试集很难平滑的完成替换而且系统规模越大风险越高。基于微服务架构使我们更容易在遗留系统上尝试新的技术或解决方案。譬如说可以先挑选风险最小的服务作为尝试快速得到反馈后再决定是否试用于其他服务。这也意味着即便对一项新技术的尝试失败也可以抛弃这个方案并不会对整个产品带来风险。 该图引用自Martin Fowler的Microservices一文 独立测试与部署 单块架构系统运行在一个进程中因此系统中任何程序的改变都需要对整个系统重新测试并部署。 而对于微服务架构而言不同服务之间的打包、测试或者部署等与其它服务都是完全独立的。对某个服务所做的改动只需要关注该服务本身。从这个角度来说使用微服务后代码修改、测试、打包以及部署的成本和风险都比单块架构系统降低很多。 按需伸缩 单块架构系统由于单进程的局限性水平扩展时只能基于整个系统进行扩展无法针对某一个功能模块按需扩展。 而服务架构则可以完美地解决伸缩性的扩展问题。系统可以根据需要实施细粒度的自由扩展。 错误隔离性 微服务架构同时也能提升故障的隔离性。例如如果某个服务的内存泄露只会影响自己其他服务能够继续正常地工作。与之形成对比的是单块架构中如果有一个不合格的组件发生异常有可能会拖垮整个系统。 团队全功能化 康威定律Conway’s law指出一个组织的设计成果其结构往往对应于这个组织中的沟通结构organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations。传统的开发模式在分工时往往以技术为单位比如UI团队、服务端团队和数据库团队这样的分工可能会导致任何功能上的改变都需要跨团队沟通和协调。而微服务则倡导围绕服务来分工团队需要具备服务设计、开发、测试到部署所需的所有技能。 4. 微服务快速开发实践 随着团队对业务的理解加深和对微服务实践的尝试数个微服务程序已经成功构建出来。不过问题同时也出现了对于这些不同的微服务程序而言虽然具体实现的代码细节不同但其结构、开发方式、持续集成环境、测试策略、部署机制以及监控和告警等都有着类似的实现方式。那么如何满足DRY原则并消除浪费呢带着这个问题经过团队的努力Stencil诞生了。 Stencil是一个帮助快速构建Ruby微服务应用的开发框架主要包括四部分Stencil模板、代码生成工具持续集成模板以及一键部署工具。 Stencil模板 Stencil模板是一个独立的Ruby代码工程库主要包括代码模板以及一组配置文件模板。 代码模板使用Webmachine作为Web框架RESTful和JSON构建服务之间的通信方式RSpec作为测试框架。同时代码模板还定义了一组Rake任务譬如运行测试查看测试报告将当前的微服务生成RPM包使用Koji给RPM包打标签等。 除此之外该模板也提供了一组通用的URL帮助使用者查看微服务的当前版本、配置信息以及检测该微服务程序是否健康运行等。 [{rel: index,path: /diagnostic/},{rel: version,path: /diagnostic/version},{rel: config,path: /diagnostic/config},{rel: hostname,path: /diagnostic/hostname},{rel: heartbeat,path: /diagnostic/status/heartbeat},{rel: nagios,path: /diagnostic/status/nagios}
] 配置文件模板主要包括NewRelic配置Passenger配置、Nagios配置、Apache配置以及Splunk配置。通过定义这些配置文件模板当把新的微服务程序部署到验收环境或者产品环境时我们立刻就可以使用Nagios、NewRelic以及Splunk等第三方服务提供的功能帮助我们有效的监控微服务并在超过初始阈值时获得告警。 代码生成工具 借助Stencil代码生成工具我们能在很短时间内就构建出一个可以立即运行的微服务应用程序。随着系统越来越复杂微服务程序的不断增多Stencil模板和代码生成工具帮助我们大大简化了创建微服务的流程让开发人员更关注如何实现业务逻辑并快速验证。 Create a project from the stencil template (version 0.1.27)--name, -n s: New project name. eg. things-and-stuff--git-owner, -g s: Git owner (default: which team or owner)--database, -d: Include database connection code--triggered-task, -t: Include triggered task code--provider, -p: Is it a service provider? (other services use this service)--consumer, -c: Is it a service consumer? (it uses other services)--branch, -b s: Specify a particular branch of Stencil--face-palm, -f: Overide name validation --help, -h: Show this message 如上代码所示通过指定不同参数我们能创建具有数据库访问能力的微服务程序或者是包含异步队列处理的微服务程序。同时我们也可以标记该服务是数据消费者还是数据生产者能帮助我们理解多个微服务之间的联系。 持续集成模板 基于持续集成服务器Bamboo团队创建了针对Stencil的持续集成模板工程并定义了三个主要阶段 打包运行单元测试集成测试等待测试通过后生成RPM包。 发布将RPM包发布到Koji服务器上并打上相应的Tag。然后使用Packer在亚马逊 AWS云环境中创建AMI建好的AMI上已经安装了当前微服务程序的最新RPM包。 部署基于指定版本的AMI将应用快速部署到验收环境或者产品环境上。 利用持续集成模板工程团队仅需花费很少的时间就可以针对新建的微应用程序在Bamboo上快速定义其对应的持续集成环境。 一键部署工具 所有的微服务程序都部署并运行在亚马逊AWS云环境上。同时我们使用Asgard对AWS云环境中的资源进行创建、部署和管理。 Asgard是一套功能强大的基于Web的AWS云部署和管理工具由Netflix采用Groovy on Grails开发其主要优点有 基于B/S的AWS部署及管理工具使用户能通过浏览器直接访问AWS云资源无需设置Secret Key和Access Key 定义了Application以及Cluster等逻辑概念更清晰、有效地描述了应用程序在AWS云环境中对应的部署拓扑结构。 在对应用的部署操作中集成了AWS Elastic Load Balancer、AWS EC2以及AWS Autoscaling Group并将这些资源自动关联起来。 提供RESTful接口能够方便地与其他系统集成。 简洁易用的用户接口提供可视化的方式完成一键部署以及流量切换。 由于Asgard对RESTful的良好支持团队实现了一套基于Asgard的命令行部署工具只需如下一条命令提供应用程序的名称以及版本号就可自动完成资源的创建、部署、流量切换、删除旧的应用等操作。 asgard-deploy [AppName] [AppVersion] 同时基于命令行的部署工具也可以很容易的将自动化部署集成到Bamboo持续集成环境。 通过使用微服务框架Stencil大大缩短了团队开发微服务的周期。同时基于Stencil我们定义了一套团队内部的开发流程帮助团队的每一位成员理解并快速构建微服务。 微服务架构下的新系统 经过5个月的努力我们重新构建了合同管理系统将之前的产品、价格、销售人员、合同签署、合同审查以及PDF生成都定义成了独立的服务接口。相比之前大而全、难以维护的合同管理系统而言新的系统由不同功能的微服务组成每个微服务程序只关注单一的功能。每个微服务应用都有相关的负责人通过使用Page Duty建立消息通知机制。每当有监控出现告警的时候责任人能立即收到消息并快速做出响应。 由于微服务具有高内聚低耦合的特点每个应用都是一个独立的个体。当出现问题时很容易定位问题并解决问题大大缩短了修复缺陷的周期。另外通过使用不同功能的微服务接口提供数据用户接口(UI)部分变成了一个非常简洁、轻量级的应用更关注如何渲染页面以及表单提交等交互功能。 总结 通过使用微服务架构在不影响现有业务运转的情况下我们有效的将遗留的大系统逐渐分解成不同功能的微服务接口。同时通过Stencil微服务开发框架我们能够快速地构建不同功能的微服务接口并能方便地将其部署到验收环境或者产品环境。最后得益于微服务架构的灵活性以及扩展性使得我们能够快速构建低耦合、易扩展、易伸缩性的应用系统。 参考文献 http://martinfowler.com/articles/microservices.html http://jaxenter.com/cracking-microservices-practices-50692.html http://microservices.io/patterns/microservices.html 转载于:https://my.oschina.net/renguijiayi/blog/545541
