精华内容
下载资源
问答
  • 计算机会计学信息系统实施步骤实验课件.pptx
  • [精选]计算机会计学信息系统实施步骤实验课件.pptx
  • ERP系统实施一般方法与步骤

    万次阅读 2018-03-15 13:50:29
    企业ERP系统实施是一项复杂且细节的系统工程,一般以项目形式完成。项目领导小组一般由企业高层领导和服务方组成,通过定期和不定期会议指导项目的运作和排除项目组难以解决的困难。项目组的构成包括服务方的咨询...

    企业ERP系统实施是一项复杂且细节的系统工程,一般以项目形式完成。项目领导小组一般由企业高层领导和服务方组成,通过定期和不定期会议指导项目的运作和排除项目组难以解决的困难。项目组的构成包括服务方的咨询顾问和企业方的关键用户。

    一、前期准备

    前期准备工作是ERP系统实施的重要环节,关系到系统实施是_台成功,应高度蕈视。主要内容包括:

    1、原理培训:培训对象主要是企业高层管理者及ERP项日组人员,目的是让他们掌握ERP的基本原理和管理思想。

    2、需求确认:参与对象主要是企业各级管理者及项日组人员,主要是对企业现行管理的业务流程和存存的问题进行归纳、总结和评议,找出企管理的症结所在,并确定解决方案,明确预期目标。

    3、确定目标:企业在实施ERP前,要理智地进行立项分析,包括企业是否具备应用ERP系统的基本条件,最迫切需要解决哪些问题,企业为ERP系统投入的资金、人力等资源能否保证系统实施,企业实施ERP系统的投资回报率有多高,最终确定是否ERP系统。

    4、系统选型:每个企业都有其特殊性,任何一套系统都不可能完全解决企业的所有问题,系统选型可以采取招标方式,既方便对比了解不同系统的优缺点,又促进投标单位的竞争而使企业最终受益。

    二、实施阶段

    1、项目组织:项目实施小组成员主要由 业信息技术部门、财务部门等主要部门的领导或业务骨干组成。

    2、方案准备:由关键用户和系统咨询颐问讨论业务流程操作的每个细节,最终确定其存系统中实现的方案。企业在系统实施前必须完成业务流程重组简BPR。企业进行BPR是实施ERP的前提、依据和基础。

    3、数据准备:在运行ERP之前,要准备和录入一系列基础数据,包括主数据和业务数据,需要做大量分析研究工作。主数据是指会被其他操作过程选用的,在系统财务、业务等不同的模块之间共享的记录数据,包括会计科目、客户、产品、银行、人员等类型的信息;业务数据是指系统切换时点反映企业状况的需要记录结转的业务、财务数据,包括财务账面所有余额、业务台账余额等信息。

    4、系统安装调试:由于ERP系统是信息集成系统,在测试时,应当是全系统测试,各部门同时参与。这样才能理解各个数据、功能和流程之间相互的集成关系,找出不足,提出解决企业财务管理问题的方案。

    5、模拟运行及用户化:在基本掌握软件功能的基础上,选择代表产品,录入必要的数据,组织项目小组进行实战性模拟,提出解决方案。可由代表不同环节的关键用户集中进行,根据企业特殊需求配置系统、开发程序等,对系统进行“客户化”工作。

    6、制定:工作准则与规程:针对实施中出现的无法由系统自动控制而必须人为干预的问题,由项目实施小组确定相应的解决方案,制定与之对应的工作准则和规程,并在实践中不断总结、完善。

    7、用户培训。由企业的关键用户在实施颐问的指导下,按照既定的系统操作规程,对最终用户进行系统操作培训。

    三、系统运用

    1、新系统上线,新旧系统并行阶段:在这个阶段,所有最终用户必须在工作岗位上的正式系统中操作,处丁真正应用状态,新的正式系统上线开始运作,业原操作方式与新系统同时运行。

    2、验收:在确认新系统运行成功后,完成必要的用户化上作,运行之前还需要经项日领导小组、项日实施小组的审批和验收通过,以确保ERP的实施质量。

    3、持续发展阶段:包括软件维护、升级和对新需求的继续丌发工作。随着市场竞争形势的发展,企业管理水平的不断提高、系统自身不断更新换代、信息技术的不断进步等各方面都会对原有系统构成新的挑战,有必要对系统实施结果做一个小结,以判断是否达到最初的目标,在此基础上制定下一步的目标,不断改进和提高。这也是ERP系统和普通应用软件的重要区别。

    本文转自UAS管理系统:www.usoftchina.com


    展开全文
  • ERP实施流程步骤

    万次阅读 多人点赞 2018-08-05 09:26:19
     主要的目的就是ERP软件提供商的实施顾问人员能够对企业各个部门的业务流程初步了解,能收集到各个部门业务流的所有单据,和各个部门人员的认识,了解他们对ERP的认识和期望,以便制订工作计划。 2.系统培训:  ...

    1.初次调研:
      主要的目的就是ERP软件提供商的实施顾问人员能够对企业各个部门的业务流程初步了解,能收集到各个部门业务流的所有单据,和各个部门人员的认识,了解他们对ERP的认识和期望,以便制订工作计划。
    2.系统培训:
      主要的目的就是能够让企业所有人员认识到什么是ERP,并在企业中应用ERP系统能给企业带来如何的效益,另外就是ERP软件的各个系统的功能培训。
    3.流程拟定:
      主要的目的是实施顾问人员根据自己对该企业的了解结合自己或所在公司对企业所在行业的累积经验,结合ERP系统拟定出一个符合企业需求的业务流程,能在系统中得到合理的体现;这是一个非常重要的阶段,一个企业的管理能否从此通过ERP得到提升,流程能否更完善,就需*这个流程拟定了。
    4.编码原则:
      主要的目的是企业能在实施顾问人员的指导下,制定企业应用ERP的基本原则,其中包括物料的编码原则、供应商、客户的编码原则、产品结构(包括BOM架阶)的分阶建立等。
    5.资料收集:
      主要的目的是企业的人员在熟悉了各项编码原则的基础上,收集企业应用ERP管理所需要的基本资料,包括物料资料、供应商、客户、部门、人员等收集。
    6.流程测试:
      主要的目的是企业的人员测试流程拟定的合理性,并使用企业实际的业务流程来测试ERP系统的功能完善性,和操作的方便性。
    7.期初导入: 
      主要的目的是搜集ERP系统上线的期初数据,并在实施顾问人员的指导下录入ERP系统,为企业正式应用ERP系统奠定夯实的基础。
    8.上线辅导:
      主要的目的是将企业的实际业务数据在ERP系统中处理,一般在系统上线的第一、二个月的时间里面,有必要的又模式进行,以防企业人员在上线期初操作不熟练所造成错误。
    9.月结辅导:
      主要的目的是在应用系统一个自然月后,通过ERP系统来跑出企业管理所需要的各种报表、检验报表的完善性,数据的准确性。
      当然,一个企业中要成功实施一个ERP系统,单纯的*以上九个步骤是远远不够的,ERP的实施是一个非常规范的过程,所以,我们在这里将这过程分作为两大块。
      
      一、以实施文档全面贯穿实施过程:
      作为实施顾问人员,在实旋的过程中,应将各种标准的实施文档提交给企业,以确保ERP实施项目的质量进行,也就是说,顾问与企业之间的工作与文档的制作息息相关,可见文档在实施进程中的重要性非同一般。
      那么,文档到底对整个实施工作有怎样的作用呢?首先,我们大致将ERP实施中的文档作为一个分类:
       分阶段实施计划文档
       分阶段目标设置文档
       标准业务流程文档
       标准编码、标准数据文档
       标准参数设置文档
       功能操作指南文档
      这些文档将会伴随着ERP实施的各个阶段逐渐充实、完善;也同时记载了整个实施的过程和成果;那好,现在我们来分析一下这些文档的价值所在:
      1.书面化的文档有助于实施人员与企业人员明确了解各自的职责,信息互通,共同把握实施过程的节奏。
      2.标准业务流程文更有助于双方明晰业务流程,有效配合业务流程的重组和优化。
      3.标准编码、数据文档及标准参数设置文档是实施中不可缺少的基础资料,可有效减少重复工作,避免对正常工作的影响。
      4.功能操作指南文档可帮助最终用户规范化操作,加强培训效果。
      前面我们曾经提到,ERP的实施工作可能长达数年不定,在这个时间跨度中,企业在最初实施ERP时确定的ERP项目的人员,也许难免要发生一些变化,那么,在发生变化时,ERP实施文档就可以承担起指导双方快速工作的标准文档的作用;还有,当实施完成后,企业的运行过程将是更漫长的过程,那么实施的标准文档就将成为企业实施信息化的公共载体了,成这指导企业后续工作的航标,和企业在后续人员培训方面提供详尽的素材。
      
      二、培训全面贯穿实施过程:
      在ERP实施的过程中,培训始终是作为一条主线的,具体点说吧,在系统实施过程中,培训对象包括以下四类:
      企业领导层、核心小组(项目负责人)、技术小组、最终用户
      1.企业领导层培训,对高层的培训主要是ERP管理理念的培训,通常会由软件提供商安排较资深顾问师对企业领导层进行ERP管理思想的培训,使得企业领导层能够从总体上理解ERP系统的理念、流程和功能。
      2.核心小组(包括项目负责人、部门经理)的培训,对於这一类的培训内容包括ERP系统的管理思想概念、ERP系统的具体功能以及ERP系统各种报表的应用。
      3.技术小组培训,技术小组的成员主要包括参与ERP系统及相关Database和网络安装、设置及管理的信息部门成员。培训的主要目标是提供ERP系统的设计结构,各个模块的关联关系与数据库结构,系统问题处理等。
      4.最终用户培训,培训目的是使用户了解ERP系统后新的业务前景、目标以及带来的好处,使用户能清楚的了解到ERP是什么,怎样通过它提高个人及整体的业务表现,使用户发角其工作内容的变化及ERP将如何融入其日常工作。同时向用户提供从现状到未来迁移过程中通用的术语,提导用户如何使用ERP完成其工作。
      ERP的实施过程中的培训作为实施的一条主线,既体现了ERP实施很高的附加值,又充分体现了ERP实施过程中的知识转移。把ERP从半成品到成品的过程实质就是知识转移的过程,其中包含企业的管理诊断,实施战略的选择,业为流程的设定,对企业需求的恰到好处的分析。
      上述中,企业信息化是一个长期的过程,在这个过程中,成熟完善的ERP系统是信息化成功的前提,严谨科学的实施方式是保证ERP成功上线的关键。

    展开全文
  • JDL公司从筹划到实施ERP系统,经过了总体规划分布实施、专项机构、教育与培训、原型测试...通过ERP管理信息系统的应用,公司各个方面的管理和控制都加强了,实现了库存管理、销售过程的控制以及成本核算等方面的转变。
  • 信息系统开发过程的四个实施阶段

    千次阅读 2019-03-03 15:52:36
    信息规划阶段 业务领域分析阶段 系统设计阶段 系统构建阶段
    展开全文
  • 业务系统是任何一个用户产品的必须组成,充当着一个门面的角色,用户的输入就是这个系统需要维护的,数据存取是整个系统的核心。例如,广告业务系统的输入是广告主的投放约束、定向条件,微博业务系统的输入是短文字...

    1. 篇首语

    业务系统是任何一个用户产品的必须组成,充当着一个门面的角色,用户的输入就是这个系统需要维护的,数据存取是整个系统的核心。例如,广告业务系统的输入是广告主的投放约束、定向条件,微博业务系统的输入是短文字、图片等。

     

    在应用发展初期或者规模不大的情况下,有非常简单的实现方案,LNMP、JSP、PyWeb都是你能随口说出来的词,如果用某种架构方式来描述,那就可以称做单体模式(Monolithic,Martin Flower大神所提出的,后面还会介绍),而这些技术都是单体模式的成熟解决方案,它们可以使你工作在“应用层”的最顶端,各种中间件、框架能让你省心地干好业务,开发人员可以通过“模块化”的手段来管理业务系统的复杂度,使他们之间解耦、复用。简单来说,这个单体就是如下这种层次划分。

     

    JAVA代码

    表示层       前端(HTML+CSS+JS)                        

      |                   |

    逻辑层     业务系统(PHP、Java、Python是常用的语言)         

      |                   |                               

    数据层      数据库(MySQL)

     

    看起来很简单,对吧。诚然,业务系统在这里面还需要做很多,比如缓存、SQL优化、数据分区、系统安全工作,当然还有对于代码的维护和重构。这种工作方式可以很好的工作几年、甚至十年,但是如果业务发展非常快,在系统复杂度、业务规模、参与人数、代码腐化程度都不断上升的情况下,你会发现整个项目正陷于泥潭,PM/RD/QA/OP经常抱怨:

     


    "改个小功能,怎么要拉这么多模块?"

    "拉模块也就罢了,改的地方多,编译太慢了。"

    "慢也就算了,关键不知道怎么改,这代码太丑陋了,算了,为了满足PM的排期需要,凑合来吧。"

    "凑合来了,QA发现bug,返工再返工,延期再延期。"

    "上线了,oh my god,报case了,性能有问题,原来是依赖的模块访问数据库用了for循环select。"


     

    透过现象看本质,我总结了来看就这三点问题:

     

    1)业务逻辑复杂耦合,开发维护成本高。

    系统复杂度、规模、参与人数都和腐化程度成正比,单纯的靠模块化,后期来看会存在个别模块成为”大怪物“,臃肿不堪,粒度过粗,难以复用。

     

    2)交付效率和质量低。

    在敏捷和持续集成方法论、实践大行其道的现今,迭代的按期交付率、单测覆盖率都不尽如人意,线上问题频发。

     

    3)非功能需求不达标。

    非功能需求指标特指性能、可用性、可扩展性等方面,代码的腐化和缺少维护、重构,以及没有代码洁癖的人污染下,必然导致性能逐渐下降,甚至出现不同资源竞争的短板效应,造成整个系统crash,同时一个大怪物的伸缩性较差,不能随意横向扩展某个细分功能点。

     

    我想任何人做架构都需要秉承“业务需求决定技术演化路线”的思路,那么这些暴露出来的现状和问题都驱动系统去转型,在系统和人之间找到一种最佳的合作模式,匹配已有的生产力和生成关系。正如软件开发学泰斗Kent Beck所说的:

    “Design is there to enable you to keep changing the software easily in the long term” ,即“变化发生时设计被破坏的程度”

     

    放眼业界,面对复杂的、大规模的、多人协作完成的业务系统,如何管理好这个复杂度,有很多方法,模块化、OSGI、传统服务化SOA等等,当今最佳实践的趋势还是服务化。而微服务是最近火热起来的概念,有些人肯定觉得这不就是炒作嘛,但是不管黑猫白猫能抓耗子就是好猫,所以解决问题是重点,不要刻意去批评一些名字,那么本文要重点介绍的就是——如何做微服务化转型和改造。

     

    在接下来讲之前,要重点声明,本文并不是推崇服务化,不鼓励单体模式,相反而是相当肯定和支持单体模式,它模块依赖简单、一个发布包、部署于一个容器都使得构建应用非常的简单,在体量还不大的情况下,首先应该解决的是搭建好一套绝对稳定的基于模块化的平台,待体量逐渐长大,再去根据实际需要进行拆分,团队也随之变化(facebook的单体持续了非常长的时间,一是人员素质高,二就是基础平台建设的非常好)。再下个阶段体量大到饱受单体模式之苦,也应该先建设平台化服务,建设好之后,先按照大的粒度进行拆分,逐步再微服务化,否则,直接上服务化、甚至下面要说的微服务都是非常危险的,鲜有成功案例。

     

    2. 微服务化改造

    做改造一般要经历三个步骤:

    第一、技术选型决策

    第二、架构设计规划

    第三、落地实施应用。

     

    下面依次展开三个部分,重点介绍前两个步骤,有了这两个,落地应用也就顺水推舟的好做了。

     

    2.1 技术选型决策

     

    2.1.1 选择微服务化方式

    选择服务化,众所周知就是SOA嘛,这是一种架构风格,重点在原则、理念、方法论等高思维层次上,对于工具、框架、解决方案没有做强制限制,ESB、websercie(基于WSDL和SOAP/BPEL)这两种是企业中流行的,也是过去一直引领SOA的技术领头羊,但是随着互联网应用的发展,在敏捷快速迭代、高可用、高性能、高并发等方面要求越来越高,传统的SOA并不适合这种场景。那么,现在的互联网流行的实现方式是什么呢?一种最佳的实践方式就是微服务化(Micro Service)。[配图1]

    \

    微服务就是一种SOA的实现方式而已,更加侧重于在服务的细分演化,是指引服务的具体落地方案层面的一种实践方式。过去很多互联网公司在实践,你可以把淘宝的dubbo、HSF,navi-rpc服务化框架看做比传统SOA更适用、更贴近微服务化实现的服务化框架,依赖这些框架可以方便的做服务化。这个趋势被Martin Flower大神所发现,并且提出了,你们这些不都是在做“微服务”嘛。

    Martin对微服务这个术语(terminology)的解释是:

     

    In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.


    简而言之,微服务化就是以一系列小的服务来开发支撑一个应用的方法论,服务独立在自己的进程中,通过轻量级通信机制交互(通常是走HTTP协议)。这些服务是围绕着业务上的组织结构来构建的,全自动的、独立部署。几乎看不到中心化的服务管理基础设施,可以使用不同的编程语言和数据存储技术来实现不同的服务。

     

    在简单的一种理解来自于一本书《Building Microservices》(Sam Newman, O’Reilly Media),Microservices are small, autonomous services that work together. 微服务化就是一堆小而自治的服务,让他们一起工作起来。

     

    相比于传统的SOA,Martin的总结特点可以参考他的博客还有视频(Youtube链接),一共是9个特点,这里不想赘述,而是说说我个人的理解,微服务化的特点在于:

     

    1、模块即服务

    微服务中的组件在逻辑或者物理层次更趋于细分,这个细分不是极致的,而是一种粒度适中的选择,通常这些组件在前期可以是一些模块,但是当需要时,例如业务上需要拆分独立,或者非功能需求上需要扩容等,都可以灵活的拆解出来。这个特点非常重要,因为业务系统中模块化实践,随着软件规模的变大,很容易绕过障碍而使得不同模块耦合、依赖关系复杂,这种纪律性很难保证,从而削弱模块化的结构、降低了团队的生产力(敏捷开发和持续交付越来越难做,部署起来太庞大了大家的开发士气不高,而且痛苦),很快的这个模块就会变成一个大杂烩,而服务可以做到天然的壁垒,仅仅通过交换契约(通常是API或者proto)来做交互,这是一个演化的过程,不仅有利于分而治之,到达复用的目的,同时老系统也可以灰度的改造剥离。

     

    2、独立自治

    这意味着服务是独立开发,独立测试,独立发布,独立部署,独立运维的。某个细分团队负责整个生命周期管理,这就是”康威定律(Conway’s law)”的通俗解释,官方解释是“一个组织的设计成果,其结构往往对应于这个组织中的沟通结构”,服务的规划不就是多人、跨团队协作的沟通模式嘛。好处在于摒弃原来的火车模型(所有模块一起发布部署),拥抱独立快跑,这也更好的支持了敏捷和持续集成的方法实践。同时去除了牵一发而动全身的问题,单一职责的来进行修改需求或者重构一个点,开发和构建方便,不影响整个产品的功能,一个bug不会crash掉整个产品,针对不同的类型,区分计算密集型还是I/O密集型,区分业务上更好使用关系型还是NoSQL,区分2/8原则、即80%经常修改的服务独立出来自成一家,区分短板功能、针对瓶颈可以做水平扩展、避免资源竞争,甚至可以区分技术栈、突破语言限制。最后,这也是和第一点遥相呼应的,独立的服务可以实现非常大程度上的复用,服务之间依赖轻量级的接口,而不是模块。

     

    3、去中心化的数据管理

    在单体模式中,一个应用面对一套数据库,数据库可以按照物理拆分,进行shard分区,或者按照逻辑库隔离,不同的业务路由到不同的库,同时做一主多从等结构上的设计。这些原则在微服务中仍然适用,只不过微服务在服务拆分的同时,也需要将数据库分离,独立的服务维护独立的数据库,这对数据库也是减负,同时技术选型、SLA保证都会区分开来,把精力留给那些重要的业务数据库,进行分级的对待,而不能像以前一样一视同仁,一个不重要的逻辑库的bad SQL慢查询,阻塞了其他正常的查询,这是完全可以避免的。

     

    4、轻量级的通信协议

    传统的SOA使用ESB或者Webservice这种重量级的解决方案,微服务推荐使用一些更轻的解决方案,要通用性,可以用Restful架构,走HTTP通道,支持Json序列化协议;要高性能,可以考虑一些高性能的I/O模型,例如epoll、Actor等,可以直接走tcp通道,使用protobuf序列化协议,同时保持长连接(这里有一个例子Navi-pbrpc就是一个这样的具体落地框架);要异步,用可靠持久的RabbitMQ或者高性能的ZeroMQ来做P2P、Pub/Sub、广播broadcast消息通信。而这种轻量级还需要体现在代码调用中,模块化直接通过函数、方法调用即可,服务化后能不能在API层面做到无侵入,无缝的切换、简单配置,这些都是服务化框架要支持的。

     

    5、为失败设计

    服务化调用从进程内in-process的调用,转变为跨进程的分布式调用,这种由分布式特性引起的天然不可靠性,需要变为相对可控。也就是服务间的通信要假设不会成功,为失败处理。异常的传递,能否透过RPC,在调用方本地还原,就像函数、方法调用一样?一个点、或者服务的处理错误率到了一个阈值,为了不影响整个产品,要做错误隔离,可以考虑熔断(circut break)、舱壁隔离模式、限流、回退等手段,最后还有一个幂等性问题,重试的调用会不会对业务造成影响,这个要具体问题具体分析了。

     

    6、基础交付设施自动化

    这个特点是整个微服务中的最大亮点,包括持续集成CI、持续交付CD和PaaS平台的结合。微服务在细分的背景下,在project结构,物理结构上都提高了一个复杂度,如果还要做到提高软件交付链路的整体效率,就需要在基础交付上做一个大的转变,因此DevOps文化,让每个人都参与交付,在规范的流程和标准的交付(例如,标准的容器)下,同时在PaaS服务提供商的帮助下,完成一个服务的自动部署发布。

     

    任何事情都是两面的,有好的优点,当然会存在弊端,微服务的缺点我的理解如下:

     

    1、分布式调用造成的性能、延迟问题。(可以采取的措施包括粒度适中、批量、高性能RPC、异步通信等)

     

    2、可靠性不好保证。(刚才提到的为失败设计可以解决)

     

    3、数据一致性难以保证。(看各自的业务,确保最终一致性即可,实际上大多数互联网产品很少不用事务;但是我目前所工作的商业产品领域,是需要事务的,除了不推荐的两段式提交,还可以引入仲裁者、补偿措施来解决分布式事务问题,问题可以单独开一篇文章介绍了,这里就不展开了)

     

    4、整体复杂度提升。服务多、依赖多、调用多、契约如何管理、监控如何做,调用链上怎么确定哪个点有问题,服务的SLA保障、性能、错误率、告警、这么多服务如何集成测试、交付容器如何上线等等问题。(通过服务治理可以有效降低微服务化复杂造成的低效,转为推动工程生产力的高效进化,同时基础交付设施的自动化可以加速研发效率,选择了微服务就等于选择了成本优先战略,投入的成本都是为了未来业务的更好发展,避免J-curve曲线式的研发模式,只有在体量大,基础设施包括服务化框架、治理能力完善的基础上,加上流程、规范以及工具和技能的辅助下,才可以真正发挥服务化的威力,否则只有自讨苦吃)

     

    2.1.2 微服务化框架和治理模型

    架构方式、原则达成了共识,你再往下看。虚的说完了来点干货,来介绍下我所在team实践的微服务化,最核心的就是微服务化框架,业界流行的阿里的框架dubbo以及淘宝内部的HSF,Navi-rpc都可以看做微服务化框架的雏形,加上服务治理中心的管理、基础交付设施的保障就可以构成完整的一套微服务框架。我们的框架(暂时仅内部使用)整体架构如下图,他由服务发布者、调用者和治理中心三者组成,属于标准的协调者模式。[配图2]

    \

    生产者中服务逻辑在Spring或者Guice等IoC框架的bean中,由IoC容器托管,为了符合模块即服务的思想,在框架层级实现了一套可插拔组件的引擎,去实现组件的扫描,需要暴露服务的发布出来,依赖别的服务的,通过字节码技术生成Rpc调用代理Stub,形成了一个基于组件的容器,通过JSR315这个规范的SPI实现对接到J2EE容器,下面的消费者结构相同。

     

    在服务启动后,首先会第一步注册自己到服务治理中心,上传自己的契约、版本上去,治理中心如果通过检查就发布出去,之后和治理中心通过长连接协议(我们采用websocket,因为现成、简单)做一个订阅发布的通道,可以供收集状态,推送服务Endpint的变更;服务消费者可以去治理中心或者Maven仓库获取契约、SDK,治理中心推送Endpoint下来,供路由进行Rpc调用,通过消费者也通过长连接协议来进行状态和统计信息的上报,供治理中心进行分析决策和反馈。


    服务治理中心为了保证高可用性,通常使用Zookeeper这个流行的开源的基于Paxos的方案,当然最近渐渐流行起来的kebernetes的etcd是基于Raft的集群共享数据、也可以做服务的发现的解决方案。

     

    随着这种分布式调用越来越频繁,就需要服务治理能力越来越强,否则就是一张混乱的、无序的Rpc调用的网,无法管理复杂度。

     

    这里建立了服务治理的模型,在下图中的服务治理中心来实现,模型从这样几个角度来考虑如何治理服务,包括通信、契约、版本、监控、安全、交付等角度,依托服务治理中心,有了这套基础设施保驾护航,服务化就可以真正做到提高研发效率、提供优雅的开发体验。[配图3]

    \

    在基础交付设施自动化上,如下图所示,体现在自动化、容器化交付这个流程中,在平台化的背景下把团队思维转换为DevOps式的,依托Docker和k8s完成了PaaS平台的对接,同时和QA一起协作完成持续交付流程的建立。[配图4]

    \

    2.2 架构设计规划

    这里所指的架构,特指组织、服务的架构设计,非部署和代码架构。

     

    下面我要介绍的,都是扣题,是已有系统的服务化改造,是一个已经存在的、复杂的、体量大的业务系统。

     

    做架构设计规划,主要分为步骤:

    1整体架构设计

    2业务领域抽象、建模

    3服务规划与层次划分

    4服务内流程、数据、契约(接口)定义和技术选型。

     

    这里主要介绍前三个步骤,第四个偏向于个例,同时需要强结合业务需求、特点分析解决,这里不做详细展开。

     

    2.2.1 整体架构设计

    还记得文章开说所说的单体模型吗?在一个复杂的、规模大的业务系统中,使用微服务化方式实现,就需要从上到下的来做整体架构,下面这张图是我所在的商业产品的业务端到检索端的架构图。[配图5]

    \

    共分为5个层次。

    第一层,模块化组装。是各个投放产品的门面,各个投放产品可以通过搭积木式的方式,组装下层服务,就可以完成一个面向用户的功能,最常见的SpringMVC技术、Java设计模式中的facade模式就属于应用到这一层的一些点。

     

    第二层,计算服务层。服务化也就是在这个层次上展开的,每一个小圆圈都是一个微服务,这是整个服务化的核心,各个服务圈出来的都是一个个服务簇,比如投放管理一个簇,报告报表一个簇。

     

    第三层,数据存储层。会针对各个业务拆分,按照物理库或者逻辑库进行隔离。

     

    第四层,广告传输层。将多shard的MySQL写入的广告增量实时传输到检索端,形成一条增量流(incremental data stream),我们通过模拟为MySQL的一个从库来捕获解析binlog实现,将binlog增量映射为语言级别的抽象类型,供下游使用,下面一层就是一个数据接收方,其他的还包括一些MQ订阅方(如导入kafka、RMQ、ZeorMQ等),HDFS存储等,这样就形成了业务系统的数据快速、高效、实时传输的目的。

     

    第五层,检索端。是广告投放系统的核心,根据媒体环境、用户特征匹配最佳的广告,进行创意的投放,你所看到了图片、H5、flash广告都是这套系统响应的,可以做到千人前面,最佳化广告主ROI与用户体验的折衷。

     

    2.2.2 业务领域抽象建模

    技术是为业务服务的,没有了业务,纯粹的讲技术都是纸上谈兵,解决问题是所有技术的出发点,微服务化也不例外。服务于业务,就需要对业务有深刻的理解,技术才能形成良好的输出。

     

    有了前一步的整体架构规划,下一步就是计算服务层中的微服务如何规划的问题,这部分最为复杂,需要深入到产品业务中。拍脑袋规划当然可以,这叫做经验直觉主义,我认为经验主义缺少规范化的表达和标准化的设计,面对未来的修改需求,其架构的生命力不会很强。所应该站在更高的视角上尝试解决,首先就是要规范化需求表达,下图就是一个投放实施的表达,使用巴克斯范式(BNF范式)表达,将投放实施分为受众、媒体、场景等定向的选择,每种定向又分为多个约束条件,逐层深入,这个规范是所有已有产品的萃取,在新产品的打造中需要遵守的,一般会和产品经理一起打造。[配图6]

    \

     然后各个投放产品进行的功能矩阵划分的标准化设计,以这些为基础,就可以有理有据的进行服务规划,抽象分解出来的服务域高内聚,职责非常清晰,服务内的实体也是建模的,如下图所示,每个包都是一个微服务。[配图7]

     \

    2.2.3 服务规划与层次划分

    基于对业务的抽象分解,在计算服务层内部,就可以进行更加细分的层次规划,先是垂直拆分为展现层、计算层、数据资源3大纵层,核心的计算层又细分为3个层次,包括业务流程处理层,通过组装下层服务完成功能;业务逻辑组件是自包含,跨产品线、高度复用的组件;下面公共服务组件是一些通用服务。然后水平划分为多个服务簇。如下图所示。[配图8]

    \

    按照之前的服务规划,将各个微服务安置其中,最上层的web-ui和api服务负责和前端js以及客户端(安卓或者iOS)API打交道,中间例如推广管理作为一个业务流程处理组件的workflow,可以调用下面的微服务进行组织,完成一个投放流程的业务场景。所有这些服务都是通过分布式服务化框架来进行通信、治理的。

     

    2.3 落地实施应用

    下面是一个已有产品改造的案例,比如一个报表服务簇,过去是一个大单体,现在按照服务化的架构,进行拆分,最为核心的就是中间这个sync-report服务,它从olap engine中查询数据,然后通过merge字面数据,提供排序,过滤,分页功能。围绕sync-report抽取了多个不同维度的缓存,保证了核心报表服务的高性能,同时上层,不管是web-ui还是api,都复用sync-report,这样上层就会很薄,不用再管那些复杂的查询逻辑,sync-report作为标准、规范的技术解决方案,做到了统一复用与专职专用,加速了研发效率和交付。[配图9]

    \

    3. 篇后语

    本文所提倡的微服务,是结合作者所在team自身业务特点来说的,适合自身的场景,是建立在团队人员素质到了,有成熟的基础设施和框架、中间件辅助,流程也规范,包括CI、敏捷等,团队都做好了准确去做这个转变,有足够的能力来实施,微服务化也就是水到渠成的事了。相反,小团队在前期或者野蛮生长时期,不宜选择微服务,不但影响效率还带来额外的复杂度。成长型或者大公司,有成熟的流程、规范、基础设施、平台等,要想在整条交付链路上加速,就需要投入更多的资源保障微服务化,一切自动化了,能治理了,回头看来这一切就都是值得的,远期收益非常可观。

     

    最后要说的是,架构只是标准、骨骼,对微服务的讨论不应该让我们忘记了更重要的问题,驱动软件项目成功和失败的重要因素。软因素如团队中人的素质,以及他们如何彼此合作、沟通,这都会对是否使用微服务有很大的影响。在纯技术层面上来讲,应该把重点放在干净的代码、完善到位的测试,并持续关注架构的演化进步,这才是一个软件工程师的根本职责。


    ——本文摘自infoQ《架构师》期刊201606期中《谈谈后端业务系统的微服务化改造》一文,作者:张旭。

    展开全文
  • 从供应链金融平台系统的整体实施来说,我们分了三个大的阶段和四个具体的环节。三个大的阶段是系统规划、研发实施和后期运营。 新创易供应链金融系统解决方案从目前IT发展的情况来说,技术上已经不是问题,我国的...
  • Java面试题大全(2020版)

    万次阅读 多人点赞 2019-11-26 11:59:06
    不能,定义抽象类就是让其他类继承的,如果定义为 final 该类就不能被继承,这样彼此就会产生矛盾,所以 final 不能修饰抽象类,如下图所示,编辑器也会提示错误信息: 14. 接口和抽象类有什么区别? 实现:抽象类...
  • 《数据库原理》— 数据库系统概论第五版习题解析

    万次阅读 多人点赞 2017-05-29 14:57:48
    数据库系统概论前七章习题解析 第1章绪论 1.试述数据、数据库、数据库系统、数据库管理系统的概念。答: (l)数据(Data):描述事物的符号记录称为数据。数据的种类有数字、文字、图形、图像、声音、正文等。...
  • 管理信息系统复习总结(保姆级)

    万次阅读 多人点赞 2021-01-01 14:19:37
    第一章 当今全球商业中的信息系统 管理信息系统的新变化:①技术(云计算、大数据与物联网、移动数字化平台) ②管理(在线合作与社会化网络软件、商务智能、虚拟会议)③组织(社会化商务、远程办公、商业价值的共创...
  • 信息系统分析与设计课程心得

    万次阅读 2017-02-28 13:41:39
    信息系统分析与设计课程心得此博客为信息系统分析与设计课程的学习心得记录。一、绪论1概念1.1信息要了解信息系统,首先要了解信息的概念。信息是我们理解世界的重要概念,我对它的定义是:信息是对客观事物及其相互...
  • SAP增强实施步骤-三代增强BADI技术

    千次阅读 2020-04-27 20:07:34
    步骤1:查找增强点,即要找到对应事务码的BADI的名称和它的方法,它的方法也就所谓的增强点,写增强代码的地方. 先运行SE24,查看类对象CL_EXITHANDLER, 在其方法:GET_INSTANCE的14行( CALL METHOD CL_EXITHANDLER...
  • 系统硬件及设备:主要包括主机服务器及其主要部件、专门的存储设备、网络交换机、路由器,等。监控方法:采用通用或者专用的管理监控工具,通常具有自动监测、跟踪和报警的功能 软件:主要针对其应用性能、软件Bug和...
  • 文章目录0.一图总览1.数据库设计概述及六步骤简介2.需求分析---步骤一2.1 收集资料2.2 分析整理2.3 数据流图2.4 数据字典2.5 用户...数据库实施---步骤五7.数据库运行维护---步骤六 0.一图总览 1.数据库设计概述及
  • 管理信息系统实施

    万次阅读 2007-03-13 16:47:00
    管理信息系统的实施提要:管理信息系统的实施是将系统设计的结果付诸实践,建立计算机硬件环境和...本章讲述管理信息系统实施的内容,实现步骤和应注意的问题.管理信息系统实施阶段的任务管理信息系统实施阶段的任务是根
  • DDoS攻击

    千次阅读 多人点赞 2019-10-16 15:32:40
    所有这些攻击目标的信息都关系到后面两个阶段的实施目标和策略,如果盲目的发动DDoS攻击就不能保证攻击目的的完成,还可能过早的暴露攻击者的身份,所以了解攻击目标是有经验的攻击者必经的步骤。 2、攻占傀儡主机...
  • 测试开发笔记

    万次阅读 多人点赞 2019-11-14 17:11:58
    测试开发笔记 第一章 测试基础 7 什么是软件测试: 7 ...验收测试:(在系统测试之后) 11 回归测试: 11 4.测试过程(干什么,怎么干) 12 5.各阶段输入、输出标准以及入口、出口准则:(测试阶段过程要素) 1...
  • 计算机组成原理

    万次阅读 多人点赞 2019-06-02 14:13:55
    PC机中称之为BIOS,开机的执行,由它来将磁盘上的操作系统引导程序装载RAM主存的固定位置,然后将控制权转交给操作系统引导程序,完成操作系统的引导。 问题: 1、为什么需要存储器容量扩展?位容量与字容量扩展...
  • 系统架构师学习笔记-信息系统基础知识

    千次阅读 多人点赞 2019-01-25 19:44:52
    目录     信息与信息系统 信息化基础 ...信息与信息系统 ...信息系统的生命周期:规划、分析、设计、实施、维护;   信息化基础 客户关系管理(CRM):客户服务与支持、 客户群维系、 商机管理; ...
  • 2016上半年信息系统管理工程师 下午试卷I (考试时间 14:00~16:30 共 150分钟) 1.在答题纸的指定位置填写你所在的省、自治区、直辖市、计划单列市的名称。 2.在答题纸的指定位置填写准考证号、出生年月日和...
  • 目录 一、瀑布模型 1.1什么是瀑布模型 1.2特点 ...2.5开发步骤 三、增量模型 3.1什么是增量模型 3.2特点 3.3优缺点 3.4作用 四、螺旋模型 4.1什么是螺旋模型 4.2特点 4.3优缺点 4.4...
  • 建模方法(四)-因子分析定义和应用

    万次阅读 多人点赞 2018-08-20 20:58:05
    这几个抽象的变量被称作“因子”,能反映原来 众多变量的主要信息。原始的变量是可观测的显在变量,而 因子一般是不可观测的潜在变量。 例如:商店的环境、商店 的服务和商品的价格作为因子,这三个方面除了价格外,...
  • 系统分析是应用系统思想和方法,把复杂的对象分解成简单的组成部分,找出这些部分的基本属性禾彼此间的关系。系统分析是系统开发中最重要、也是最困难的阶段。结构化系统分析方法及数据流图、数据字典,面向对象系统...
  • 信息系统开发方法-生命周期法

    千次阅读 2020-06-29 21:35:14
    生命周期法就是按照信息系统生命周期的各个阶段划分任务,且每个阶段有相对独立的任务,然后按一定的规则和步骤,有效地进行信息系统开发的方法。 生命周期按阶段划分,提出的是组织、管理和控制信息系统开发过程的一...
  • 软件测试面试题汇总

    万次阅读 多人点赞 2018-09-27 12:31:09
    2、我现在有个程序,发现在Windows上运行得很慢,怎么判别是程序存在问题还是软硬件系统存在问题?   5 3、测试的策略有哪些? ................................................................................
  • 管理信息系统开发流程

    万次阅读 2016-08-25 13:25:13
    一、需求分析 (一)系统开发建议 (二)可行性分析 (三)业务需求规范说明书 ...(二)系统调试:根据系统说明书和系统实施方案,对程序设计的结果进行全面的检查,找出并纠正其中的错误,把错误
  • 信息系统基础知识---信息系统概述

    千次阅读 2018-11-26 15:20:13
    信息系统是一个由人、计算机等组成的能进行信息的收集、传递、存储、加工、维护和使用的系统,它是一门综合了经济管理理论、运筹学、统计学、计算机科学的系统性和边缘性学科,是一门尚处在不断发展完善的多元目的的...
  • 管理信息系统(MIS)期末复习参考指南

    千次阅读 2019-12-03 16:28:11
    原则 步骤 关键成功因素法(CSF) 战略目标集转化法(SST) 企业系统规划法(BSP) 信息系统分析 可行性研究 内容 特点 过程 系统详细调查的方法 信息系统设计 系统设计的原则 内容 信息系统实施、运行、维护 程序...
  • 信息系统分析与设计(自考)

    千次阅读 2020-04-12 17:11:36
    1、信息系统: 是指在经济或社会的组织中,以满足管理者的信息需求为目标、以计算机和现代通信技术 等现代信息技术为手段,既包括设备和技术,又包括人员与机构在内的综合系统。 2、CASE: 就是一类专门用来帮助...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 90,006
精华内容 36,002
关键字:

信息系统实施步骤