企业应用

因为技术的提高，古代企业应用无需从头开始开发，而能够利用企业应用平台，通过组件化、低代码乃至无代码的形式来构建，以取得更高的品质、性能和交付速度。本文提出企业应用平台的一种以元数据为核心的、基于六大引擎的架构。平台以元数据和业务畛域为核心，六大引擎环绕着核心，为企业应用的开发提供弱小的赋能。有人可能会质疑低代码开发模式，而我认为这次要是因为低代码开发还没有失去古代软件工程的赋能，所以不够好用，因而将来的一个重要策略方向就是用古代软件工程来赋能低代码开发，即低代码软件工程（当前能够探讨这一话题）。每一个引擎都是一个产品，能够由一个团队来负责开发和保护。能够基于开源产品做二次开发，然而肯定要齐全把握每一个引擎，能力确保平台的整体的高质量。这六大引擎是： 数据引擎：负责数据的建模、治理和存取，为其余引擎提供数据源。换言之，是对数据库的一种高层封装机制。它比拟像Martin Fowler所述三层架构中的数据源层，或者DDD（畛域驱动设计）中的Repository概念，然而有所不同。这是最重要的一个引擎，因为能够说企业应用都是面向数据的，是围绕数据而建的。数据引擎要反对对象关系映射，要能主动治理DB schema（例如主动建表）。最好还可能内置软删除、草稿、审计等性能，这几样性能适宜对立建设，不须要让下层利用进行反复建设。数据引擎的底层是ORM框架，市面上没有适合的数据引擎产品（Supabase勉强算一个）或ORM框架（JPA勉强算一个），倡议全新开发。您可能会问，它与ORM框架有什么区别呢？最次要的区别为，数据引擎反对低代码开发模式，甚至能实时创立和批改数据模型而无需重启服务器。体现引擎：负责各种数据交换的建模、治理和执行，例如为数据类型主动导出CRUD API、将数据记录转换成适宜UI显示的VO（视图对象）或适宜API应用的DTO（数据传输对象）。这个引擎也相当重要，后文会介绍它为什么如此重要。市面上没有适合的体现引擎产品，须要全新开发。平安引擎：负责安全策略的建模、治理和执行，其中一项比较显著的性能是对数据拜访权限的治理。对于器重平安和权限的企业应用，平安引擎是很重要的。市面上没有适合的平安引擎产品，须要全新开发。规定引擎：负责业务规定的建模、治理和执行，业务规定能够用规定语言或图形化编辑的形式来编写，能够在运行时动静更新。规定引擎不是必要的（您也能够在零碎代码中硬编码所有的业务规定），然而很实用，它让业务规定能被更简略更疾速地交付。市面上有一些开源规定引擎如Drools，也有一些脚本引擎如Groovy、AviatorScript、MVEL等能够被当作繁难的规定引擎来用。以上这些产品都须要用户手动用脚本代码的模式来编写规定。还有一些商业规定引擎反对低代码的可视化开发。这些引擎产品不反对元数据，所以要么将它们通过二次开发再应用，要么开发全新的引擎产品。因为脚本引擎产品大多有较高的内聚性和成熟度，能够当成一个程序库来用，倡议采纳二次开发的形式。流程引擎：负责业务流程的建模、治理和执行，业务流程能够用流程语言或图形化编辑的形式来编写，能够在运行时动静更新。流程引擎不是必要的（您也能够在零碎代码中硬编码所有的业务流程），然而很实用，它让业务流程能被更简略更疾速地交付。流程引擎个别都反对低代码的可视化开发。市面上的开源流程引擎有jBPM、Activity、Flowable等，它们都基于一种名为BPMN的流程定义语言标准，也有一些流程引擎如Temporal、Step Functions、Apache DolphinScheduler不基于BPMN标准。这些引擎产品不反对元数据，所以要么将它们通过二次开发再应用，要么开发全新的引擎产品。因为BPMN系流程引擎产品大多简单臃肿，可扩展性差，因而咱们倡议基于非BPMN系产品做二次开发或者间接全新开发。智能引擎：负责各种智能（报表、商业智能和人工智能）的建模、治理和执行。在现在的智能时代，简直没有企业会放弃建设智能零碎，智能引擎的重要性显而易见。智能是一个前沿畛域，还须要更多摸索。为什么以元数据为核心？一个架构至多须要一种能在其外部通用的数据交换格局，例如因特网是基于包(packet)的。元数据就是这么一种格局，它是各个引擎之间的次要沟通桥梁，也是低代码开发的外围要件。元数据能够被示意为JSON或YAML格局的配置数据，它是在数据之上的对于数据结构和语义的形容信息。开发者在构建企业应用时，个别会应用SQL DDL创立一些数据库的表(database tables)，并且编写一些实体类(entity classes)的代码（例如Java代码）。您能够大抵认为，元数据对应的就是实体类的定义（实际上元数据能够蕴含实体模型、视图模型、权限模型等多种信息）。请设想一个典型的低代码开发过程： 有一款在线可视化编辑器，容许您在GUI上即时创立一个实体类。您能够创立一个User类，给它增加一些字段（例如name, country, age），而后一保留，这个实体类的定义就在零碎中失效了（能够存储和查问User信息了），无需手动编写实体类代码。这个编辑器所保留的信息就是元数据，它记录了这个实体类的定义。以上性能是利用数据引擎实现的。进一步，您还能够在线创立一个视图，它基于方才那个实体类(User)，然而只蕴含一些想展示的字段(name, country)，排除了某些不想展示的字段(age)，并且能够附带某些过滤条件表达式(country=currentUser.country)，即通过这个视图只能查问到那些与以后用户属于同一个国家的用户。以上性能是利用体现引擎实现的。您能够间接在代码中拜访这个视图，也能够为这个视图主动导出一个Web API。您也能够创立一个角色(Role)，把视图绑定到此角色，再把角色授予某些用户，那么这些用户在拜访User信息时就只能看见这个视图，而不能看见原始的User类。这样一来，用户就只能看见容许被受权给他们的数据，而不能看见全量数据。以上性能是利用平安引擎实现的。您能够创立一个业务规定，将触发机会设在User类的数据被删除之后(afterDelete)，此规定会查找行将被删除的这个User所领有的资产数据，将这些资产数据标记为解冻状态。以上性能是利用规定引擎实现的。您能够创立一个业务流程，将触发机会设在User类的数据被删除之前，此流程会发动一个审批流程，只有实现了审批流程，才会执行删除操作。以上性能是利用流程引擎实现的。您能够创立一个有用的视图并把它主动导出为一个报表。您也能够编写一些代码，通过对元数据做一些操作来生成报表。以上性能是对智能引擎的简略利用。现在大数据畛域也在强调“元数据管理”(例如Apache Atlas)，这与咱们的指标其实是统一的，将企业应用平台的元数据与大数据平台的元数据连通，是对元数据的一种很好的利用形式。 为什么是基于引擎的架构？根据康威定律，零碎的架构实际上是由组织的沟通构造所决定的。提出引擎这一形象，就是为了让企业应用平台的架构适应个别组织的沟通构造。每个引擎都是一个内聚的畛域，能够由专门的团队来负责。元数据作为各个引擎之间的次要沟通桥梁，引擎之间也能够通过引擎的API沟通，下层利用则和元数据和各个引擎的API沟通。其实一些企业应用平台已有向这种架构格调倒退的趋势，本文只是推动它的正式化。 为什么是六个？本文只提出了最重要的六大引擎，这是一个偶合的数字，但您也能够认为它与六边形架构（hexagonal architecture）是有所响应的。除此六大引擎，当然还能够有其余引擎，但其重要性绝对较低。咱们只关注这六大引擎，而它们的组合足以用于构建大多数的企业应用。 能够采纳微服务架构吗？这是一个值得答复的问题。答复是：能够，但有所限度。基于平台的业务利用当然能够用微服务架构来建设，但这个平台自身并不适宜微服务架构。如果您想将每个引擎做成一个微服务，不倡议这么做。引擎之间的分割比拟严密而且细粒度，每个引擎一个微服务的形式不利于性能和可靠性，我见过一些失败的引擎微服务架构尝试。举荐的总体架构是，每个业务利用被部署为一个服务，在每个服务中同时部署了所有的引擎。

在咱们访问过上百家企业之后，发现了一个很令人痛心但不得不抵赖的事实——最着急忙慌要数字化转型是大企业，然而，最难实现数字化转型的，也是大企业。各大投资者和厂商都在高呼：大型企业要连忙数字化转型啊！不能停留在过来啊！要有翻新思维和意识啊！是大型企业本人不想转型吗？不是的！大象转身不是一件容易的事件，大型企业数字化转型面临的难题不比中小企业小。 不转型，必淘汰很多人可能会问，既然大型企业数字化转型难，那不转型行不行？这个问题市场曾经给了咱们答案。大型企业抉择不数字化转型，必然会面临这样的结果—— 他们将会始终在软件开发和交付过程中苦苦挣扎，而因为软件开发的长周期性，我的项目失败、返工、错过最初期限、老本超支以及新产品市场适应性差将成为粗茶淡饭。更有甚者，部门企业还承当了更加危险的结果—— 他们难以跟上一直倒退的科技公司的步调。不得不被动进行必要的数字化转型以服务于他们的市场并与新的参与者和颠覆者竞争，这是一个苦楚的过程，有时甚至会齐全失败。大型企业不数字化转型，随着工夫的增长，你的客户，你的市场终将会被其余先进的科技公司一步步瓜分掉。 想转型，难题多大企业做什么转型都难，因为尾大难掉，因为积重难返，因为冰冻三尺非一日之寒。但，到底是什么“尾”，又是什么“重”，以及到底是什么“冰”呢？（1）尾：遗留旧零碎多乍一看，大型企业数字化转型的最大难点在于企业规模大，但仔细观察就会发现，规模并不是真正的妨碍因素。对于大型企业来说，像SAP、OA、CRM等外围管理系统都曾经上了个遍，企业破费了有数工夫和金钱重复优化这些老的零碎和流程，最终却只能以旧基础设施的拼凑而告终。这些遗留零碎拖慢了大型企业的速度并且造成结构性劣势，想丢丢不掉，想带带不动，成为妨碍企业提高的最大阻碍。一位CIO的吐槽对于大型解决遗留零碎的现状十分贴切： 咱们想要构建一个供整个企业应用的新数字化应用程序，须要与50多个其余IT系统集成，如果其中任何一个零碎是旧的，就会影响新应用程序的性能。不可避免的是，这50个零碎中大部分都是旧零碎！这种景象在大型企业中是广泛的，但并不是无奈解决的—— API+webhook，直插外部遗留零碎API，简略来说就是为具备编程能力的用户提供了一个简略的办法来整合新零碎数据与企业遗留零碎数据。有了 API，企业能够通过业余接口将遗留零碎的数据写入新零碎，也能够在新零碎中查问遗留零碎的数据，不便企业解决多方零碎的数据。 这么说大家可能不是很明确，举几个简道云用户的理论利用例子—— 国银通宝的遗留零碎次要是用于治理仓库货物的 ERP 软件，然而这个 ERP 零碎却不反对手机上报销。简道云则是一个反对企业搭建个性化利用的平台，国银通宝能够在简道云上间接搭建一个报销管理系统。然而总不可能报销零碎在简道云上，货物治理在 ERP 零碎上。此时 API 接口就派上了大用场，通过简道云凋谢的 API 接口，国银通宝把简道云和 ERP 零碎的性能对接起来，相当于用两个软件的性能，但数据又是彻底买通的。 中铁大桥有自研的信息平台，但少数我的项目数据习惯于纸质治理，同时，因为数据库的独立性，备份数据须要辗转操作。通过导出 Excel 进行数据备份，操作机械化、辗转费时。他们通过API 将简道云直接插入公司数据库，数据可在桥科院自研的信息平台上对立展现；再通过 webhook 把数据推送到服务器做备份。 （2）重和冰：敏捷性有余中小型公司十分麻利，能够在须要时疾速响应，他们的数字化转型用小步快走来形容最合适不过。所以这些公司可能解决多个相互竞争的优先事项，适应一直倒退的公司策略，无效地治理来自销售、客户胜利和客户的源源不断的性能申请。如此灵便和响应迅速对于大型企业来说是不太可能的。因为大公司尤其是传统大型企业，广泛有着重大的筒仓构造—— 筒仓相似于深井，指组织里不同的人都生存在一个个的深井里，深井里的人相互不联系不意识，或者见面都是争资源、争体现，他们的眼光都只盯着井下面的那个人，就只有下层领导可能指挥底下的井里的人。那么，大型企业的敏捷性问题无解了吗？并非像苹果、谷歌、华为、阿里这样的公司领有同样宏大的员工队伍，但他们仍旧在响应一直变动的市场需求和要求的同时一直推出新产品。 为什么这些公司可能做到，而其余大型企业却做不到呢？那是因为这些公司尽管规模宏大，然而他们的构造就像小型科技公司一样——他们专一于产品，而不是我的项目。并在所有产品团队和组织的范畴内施行麻利实际——而不仅仅是开发。而许多大型企业尤其是传统企业，还在依赖古老的办法和工具，例如专一于我的项目，将精力投入到简短且不灵便的需要文档中，在为时已晚时收集反馈等，导致企业陷入低效的循环之中。到这里可能会有人反驳了，实用于科技互联网公司的办法与实用于传统大型企业的办法存在基本不同，但事实并非如此。当初的经济是数字经济，这意味着所有公司都必须是科技互联网公司所有公司，尤其是大型企业，当初都要向科技互联网公司聚拢，或者至多他们必须要有这样的意识。 比如说蒙牛——作为领有4万多员工的大型国民传统企业，蒙牛同样也面临着下面这些难题—— 比方像SAP、OA、CRM等传统的外围管理系统曾经上了个遍；比方企业的治理半径十分大，其生产制作环境中不足数字化根底和人才；比方一直新增的各种IT数字化需要期待实现；比方存在很多企业外围管理系统触达不到的“真空地带”；......在这样的背景下，蒙牛引入了零代码开发平台简道云，作为他们疾速实现并迭代业务需要的工具。一年多工夫里，蒙牛造就了500多名来自业务部门的全民开发者，他们不会编程，却用简道云搭建了销售治理、行政办公、生产治理等约400个治理利用，让业务场景的各个角落都失去了效率晋升，简直实现了全员数字化。 点击查看零代码开发平台：https://www.jiandaoyun.com 蒙牛各部门员工自主开发的治理利用在通过近一年的应用之后，蒙牛认为简道云在团体数字化建设之中，不仅作为一项利用工具晋升了组织的工作效率，还进步了非核心业务场景下的数字化程度，填补了原有外围零碎边界外的“IT真空”。总之，对于大型企业尤其是传统大型企业来说，数字化转型遇到的难题绝对于中小企业更加辣手。企业治理架构曾经成型，遗留旧零碎多，敏捷性差，这些都是数字化转型的拦路虎。然而不能因为大象转身难就不转身了，还是有很多企业克服了这些艰难，实现了数字化转型，走在大型企业转型的前列，无妨多去看看他们是怎么做的，置信能带给你很多启发！

随着社会经济的疾速倒退和科学技术的全面进步，政企数字化转型已跑步进入减速期。2022 年上半年国内多地疫情突发、频发，进一步推动了政企数字化转型从前端用户触达向后端业务流程改革的深刻，减速了业务流程和经营治理的线上线下一体化过程。而随着 5G、云计算等新一代信息技术的一直改革，挪动数字化已成为政企数字化转型的划时代新命题。关注【融云 RongCloud】，理解协同办公平台更多干货。 从沟通到协同政企用户需要关注点变迁中国企业信息化倒退了 30 余年，从最早的 OA、财务零碎到起初的 SAP、ERP、Core Banking、CRM 和运营商 BOSS 零碎等，根底业务外围零碎构建得曾经很齐备了。以后政企对办公新零碎的构建需要，少数是为了适应社会新形态、反对新业态或新业务。 比方，新批发畛域政企组织基于挪动互联网时代 “以消费者为外围、线上线下相结合”的新批发特点，通过搭建 SCRM（社会化客户关系治理）零碎，对不同渠道、不同接触点客户数据进行整合剖析，从而对用户进行分层治理和精准营销，通过全流程数字化治理，晋升用户转化率和用户粘性。 在协同办公畛域，随着市场竞争日趋激烈，粗放式经营已不合乎政企倒退需要，精细化经营成为政企降本增效的“救命丸”。政企对挪动办公协同工具的需要，也不再是繁多的沟通性能，而更多要求助力业务的整体协同。所以纵观政企数字化转型倒退历程能够发现，用户需要关注点日渐多元，曾经从关注零碎根底性能向拓展更多翻新性能转变，从聚焦沟通问题向解决业务协同转变。 从人找事到事找人政企用户具体需要变方向晚期办公零碎次要解决的是“人找事”的问题，比方用户须要被动登录 OA 或者 ERP 能力发现待办或者审批流程，如果用户不登录，就能够永远无“事”。当初 IBM 要求每个员工都装置 Lotus Sametime（实时合作平台），但很多员工明明坐在工位却并不关上和登录，因为大家晓得，登录后就可能有“事”。 随着挪动互联网的倒退和智能手机的遍及，很多传统 OA 厂商和挪动信息化畛域厂商开始发力挪动审批待办平台。大略在 2016 年，钉钉和企业微信等挪动协同办公工具以收费为切入点，增强对中小企业教育，使其认同搭建挪动办公协同平台实现即时通讯是企业倒退必需品。与此同时，也开始向局部大型企业浸透。 正是这些挪动办公协同平台的呈现，使得很多人的工作和生存交错在一起，无奈离开。通过即时通讯性能，员工可随时随地审批或报备工作，甚至不必登录即可收到待办揭示，从前的“人找事”也开始向“事找人”转变。 从性能角度讲，政企用户对协同办公平台的具体需要开始从以待办、审批、信息聚合为主的聚合平台，向以即时通讯为根底的兼具待办、审批、信息聚合等性能的挪动办公门户类平台转变。 从全聚合到局部聚合对立门户+翻新单列成必然趋势大型国央企呈多业态、多业务和多场景的倒退态势，外部零碎繁多，有些政企组织利用零碎甚至过百，入口繁多，操作繁冗，信息和数据无奈互通，用户体验差，协同效率低。为解决上述问题，搭建一套可聚合多款利用零碎的挪动办公协同平台并实现对立入口势在必行。 对用户而言，所谓挪动办公协同平台能够了解成外面搭载了 N 个零碎的服务于通用场景的超级 APP，用户可通过对立入口单点登录，在一个利用内拜访 N 个零碎；对政企组织而言，挪动办公协同平台能更好地连贯内外部客户、买通上下游供应链，让办公的人聚合、信息聚合、过程聚合，最终实现管控集中化、信息共享化和经营智能化，更快地推动数智化转型降级。 当然，为方便管理，挪动办公协同平台可通过分级和分权治理实现“千人千面”，即不同部门不同级别的人享有的权限不同，每个人在挪动端均可拜访集体权限内的所有内容和性能，所有操作也可在挪动端实现。 然而，正因为政企需要日益多元化，零碎日渐增多，所以将所有零碎全副接入挪动办公协同平台也不事实。比方为满足新业态、新业务或新场景个性化需要而搭建的创新型零碎，可容许其独立存在，不用对立接入平台。 搭建挪动办公协同平台，是为了晋升协同效率，而容许某些零碎独立存在，则是为了兼顾政企组织在翻新业务上的灵活性。 比方，某化工企业上线了一款平安生产类 App，仅供内部人员巡检油库报备状况应用，与现有业务并无穿插，信息业务业务互通需要，所以这种 App 就没必要接入平台。 从标准化到个性化是否定制化成政企选型硬指标挪动办公协同平台不乏明星产品，明星产品尽管能带给用户良好的应用体验，但在满足政企重而繁冗的个性化需要方面，并不具备显著劣势。因明星产品多属于规范产品，零碎开放性较弱，对二次开发并不敌对，定制化施行完成度低。 尤其中国企业跟东方企业有很大的不同，很少有国家像咱们国家这样，有这么多业态多、业务多、场景多的大型企业，而且这些大型企业始终以来根本都依照中国特色搭建管理系统、流程零碎等，并不间接抉择标准化产品。 所以，政企在抉择挪动办公协同平台产品时，往往更关注产品是否满足本身多样化、个性化需要。 融云，能为不同行业打造挪动办公协同平台，提供基于行业属性及政企个性化需要的定制化专属解决方案，为政企内外部人员提供便捷对立的通信和业务协同服务，满足全员随时随地的沟通和合作。也可依据业务、场景多样化需要，封装场景化 SDK，提供上百种规范 API 接口，便于各细分场景灵便调用。另外，融云产品还反对开箱即用，对立入口，可与政企现有 OA、邮件、CRM 及其他第三方零碎疾速集成，买通业务办公内外循环。 融云产品在 Android、iOS、Web、小程序等多端已实现整体兼容，冲破时空限度，让合作无时无处不在。当然，为满足政企用户高平安需要，融云还可依据客户需要，将服务集群部署在公有基础设施上，让数据可控、平安有保障、资源可自主调配。政企数智化转型正过后，挪动办公协同平台是重要一步。将来，融云将依靠 IM 即时通讯和 RTC 实时音视频带来的全通信能力，以及一直精进的通信产品和继续优化的解决方案，针对不同行业数智化转型的重点和门路，帮助政企组织在泛滥细分场景中真正实现降本增效，帮忙政企组织构建外围竞争力，在强烈的数字时代竞争中怀才不遇。

企业通讯录作为企业对立通信中其它业务性能的触发点，须要灵便、齐备的性能和好用、便捷的人机界面，以便用户顺利完成业务合作，真正为企业运行提速，实现降本增效。关注【融云 RongCloud】，理解协同办公平台更多干货。 之前，咱们已分享过【在“企业通讯录”的盲区，融云的边界与分寸】和【云办公时代，企业通讯录的技术选型】。本文将论述企业级通讯录的设计与实现。 需要剖析企业通讯录须要提供的基本功能如下： 反对企业依照组织架构呈树形展现。反对视图显示。反对管理员在治理后盾对部门、员工信息以及组织架构进行查看和更改。反对管理人员对部门节点和员工节点的增、删、改、查操作。反对细粒度拜访权限管制。对不同员工设置不同的拜访权限，企业管理人员领有所有操作权限。反对通讯录信息实时同步。员工或部门信息甚至企业架构发生变化时，须要及时告诉受影响的客户端进行通讯录信息的同步。反对点击好友触发语音会议、即时消息、视频会议、企业直播等通信业务。提供对立认证服务。用户只需登录一次，在一段时间内能够应用企业提供的其它服务。其中，通讯录信息实时同步、细粒度拜访权限管制以及对立认证服务是外围性能。 通讯录信息实时同步保障了用户本地通讯录与服务端通讯录的一致性；细粒度拜访权限管制保障了用户可能取得正确的通讯录信息；对立认证服务保障了企业非法用户无需反复认证即可应用零碎受权服务。 通讯录架构设计基于企业通讯录性能需要，通讯录服务器架构设计如图 1，将通讯录架构层分为应用层、接口接入层、对立认证层、服务层和数据库接入层，各模块之间的通信采纳音讯总线的形式，即模块之间不会间接发送音讯而是将音讯发送到音讯队列中，采纳这种通信形式能够升高模块之间的耦合度，便于零碎模块的扩大和保护。图 1 - 零碎架构图 性能与模块业务零碎功能模块如图 2 企业通讯录服务功能模块结构图所示，客户端通过 HTTP 协定调用服务端提供的 Webservice 接口服务。 如果依照服务对象辨别，可分为三类服务。一类是为 Web 端提供服务称为 Web 端服务。一类是为挪动终端提供的服务称为挪动端服务。还有一类是整个零碎的保障性服务，为 Web 端提供的服务称为根底服务。 【Web 端服务】Web 端服务次要是治理类的，蕴含角色治理、权限治理、通讯录治理、日志治理、企业治理以及系统管理等。图 2 - 功能模块结构图 √ 角色治理和权限管理模块是用来实现员工拜访权限管制的√ 通讯录治理用于增、删、改、查节点信息√ 日志治理负责日志文件的增、查、操纵√ 企业治理次要实现对企业的增、删、改、查操作√ 系统管理次要实现对企业管理员的治理 【挪动端服务】为挪动终端提供的次要是通讯录的获取以及更新服务。挪动终端的首次登录须要获取本人对应角色的通讯录，如果服务端通讯录信息发生变化，本地终端的通讯录须要同步更新，由通讯录同步模块实现。 【根底服务】根底服务包含对立认证和平安模块，对立认证包含身份认证、单点登录；平安模块确保通讯录服务的数据传输安全可靠。 单点登录是指当用户申请通讯录服务时，服务端须要对申请用户的合法性进行验证，非法用户零碎会提供通讯录服务，否则返回无权拜访提醒。用户在服务申请中会波及到如图 3 所示认证过程。图 3 - 权限认证流程 ① 客户端向服务端发送通讯录信息同步申请② 通讯录服务收到申请音讯，会调用验证模块验证用户的合法性，即判断用户是否己登录，已登录执行步骤 ⑤，未登录执行步骤 ③③ 如用户未登录，客户端返回身份认证页面④ 用户在身份认证页面填写用户名、明码等相应认证信息进行验证⑤ 如用户已登录，则依据用户角色取得拜访权限⑥ 拜访 LDAP 数据库，取得通讯录信息⑦ 服务端返回相应通讯录信息 为减少企业通讯录信息传输的安全性，客户端与服务端之间的数据传输本文采纳 SSL/TLS 加密，对存储在数据库中的数据进行加密存储，以防泄露。 交融通信企业通讯录业务相干接口通讯录服务须要对企业通信业务提供绝对应的接口反对，还要辅助其它业务取得通信的相干信息。如图 4 所示，企业通讯录服务提供了宽泛的接口反对企业通信业务和其它业务。 【I1 接口】存在于客户端与服务端之间，次要性能如下：√ 应用 RESTful 实现客户端对服务端的查问和更新申请√ 采纳 TLS 平安协定保障信息数据的平安传输图 4 - 通讯录接口示意图 ...

拉至文末 加入抽奖 随着 5G 技术的衰亡，以及各种智能终端的遍及，云办公市场迎来减速发展期。关注【融云 RongCloud】，理解协同办公平台更多干货。 更加灵便、高效的跨平台挪动协同办公已成支流，企业通讯录作为企业协同办公的外围根底和触发对立通信及其它相干业务的入口，重要性显而易见。 时至今日，企业通讯录，已不只是通讯录。图 1 - 企业级通讯录入口概念 企业通讯录核心技术 LDAP因为历史起因，各企业会采纳公有或其它不同规范实现通讯录性能，这样就造成了网络中存在不同的地址薄零碎服务，导致用户的通讯录数据不统一。 为此，开放式挪动联盟（OMA，Open Mobile Alliance）提出了交融地址簿（CAB，Converged Address Book）钻研我的项目，目标是造成一个对立的地址薄零碎规范，使得所有用户及业务能够共享该地址薄，从而进步服务质量，改善用户体验。 通讯录的规范除了 CAB 外，还有富通信技术标准 RCS（Rich Communication Suite）。RCS 也是一个标准化组织，由欧洲运营商发动成立，目前己被纳入了 GSM Assiciation（寰球挪动通信零碎协会）。RCS 次要是由 EAB（加强地址薄）和 NAB（网络地址薄）组成，不过 RCS 中制订的通讯录规范，是集体通讯录规范。 EAB 是本地集体通讯录零碎的扩大，NAB 是给本地通讯录 EAB 减少了网络性能，用户能够将本地创立的通讯录 EAB 上传到网络中，而本地通讯录的同步与治理不必负责。 尽管 CAB 和 RCS 都对通讯录业务作了实现上的规范定义，如通讯录的数据模型定义，须要具备哪些业务性能等，但这些规范是为集体通讯录定制的，并没有思考到企业通讯录的业务场景和安全性。而协同办公的通讯录业务与上述规范存在较大差别，因而在钻研企业通讯录时，必须结合实际利用场景，而不能全盘模拟以上两种规范。 以后，很多企业通讯录次要采纳 LDAP 实现“平安通信”的性能，以下将就 LDAP 原理和特点开展介绍。 LDAP 协定钻研LDAP（Lightweight Directory Access Protocol）即轻量级目录拜访协定，诞生于美国密歇根大学。 LDAP 优化了查问速度，采纳树状信息存储模式，可分布式部署，访问控制灵便，凭借着开放性、扩展性以及易于开发等劣势成为一款规范的目录拜访协定，已被广泛应用于基础性的信息管理系统中。 LDAP 原理LDAP 协定由四大模型形成：信息模型：用于形容 LDAP 的信息示意形式 【属性】LDAP 目录服务的存储基于条目（Entry），每个条目蕴含一组属性，用来示意事实世界中实在的实体信息，条目与属性的关系如下图：图 2 - 条目、属性、值之间关系 【对象类】事实世界中实体之间往往具备一些雷同或类似的个性，被划分为不同的类在 IDAP 目录服务中。目录条目中还蕴含了一个重要属性即对象类（objectclass）属性，该属性决定了目录条目中必须蕴含以及可能蕴含哪些属性，其中必须蕴含的属性称为强制性的（mandatory），可能蕴含的属性称为可选的（optional）。 ...

次要是为了不再被卡脖子。 金山办公，作为国内惟一能够代替office的软件，目前有很多国企都在陆续从office更换成WPS了，就是为了怕被鬼佬卡脖子，而且金山办公的小程序也很好用，我感觉将来可期啊~ WPS和office是目前我国最大的两个办公软件，其中WPS是国产的，office是微软开发的。 这两大办公软件过来30年的工夫，能够说是恩怨情仇，此起彼伏。 微软office是在1985年的时候就推出了，而WPS是在1988年才推出的，然而在WPS推出的时候，微软 Office还没有进入中国市场，所以wps有一个十分好的成长空间，从1988年到1995年， WPS在国内的市场份额十分高，始终达到90%以上，能够说是“天下无敌”。 然而到了1994年，微软office正式进入中国市场，随后WPS的位置开始逐步降落，毕竟WPS再牛你也得依赖于微软的零碎，而微软office自身就是微软开发的，它就是微软整个生态当中的一环，所以在电脑上运行十分晦涩，而且很多电脑都是自带微软office。 凭着这种生态劣势office在进入中国市场之后长驱直入，抢走了WPS的很多市场份额。 眼看着本人的地盘被office抢占，这时候WPS跟微软又签订了一个协定，那就是让WPS跟office兼容，这一招间接让WPS成为了市场的弃儿。 因为office在进入中国之后，其实产生了很多盗版，这些盗版的价格远远要低于正版的价格，几块钱就能够买到，然而对于这些盗版行为，微软并没有当一回事，而是放任不管。 过后WPS也有一些盗版，只是WPS对这些盗版的打击力度十分大，所以市场上真正呈现 WPS盗版的其实比拟少。 微软放任盗版的这种“精明”间接成为接击垮WPS的一个重要伎俩，在盗版泛滥的状况下，很多电脑都间接装置office，后果应用WPS的人越来越少，WPS的市场份额越来越低，进入2000年之后，WPS简直曾经被大家缓缓忘记了。 只不过最近几年工夫，WPS又逐步复原了市场位置， WPS在国内办公软件市场上的份额也越来越多，目前WPS寰球月沉闷用户至多达到4亿以上，尽管这个用户量跟微软10几亿相比依然有很大的差距，但在国内办公软件市场当中，WPS跟office曾经并驾齐驱，甚至曾经超过微软office；目前WPS国内月沉闷用户曾经超过2.6亿，这个沉闷用户甚至曾经超过office国内沉闷用户。 为什么最近几年应用WPS的用户越来越多？ 这里，我感觉次要有几个方面的起因。 1、WPS更符合中国用户的应用习惯。 微软的office是针对寰球用户的，所以在模板方面绝对比拟全球化，有很多性能不肯定实用中国用户。 而WPS从一开始诞生就次要针对国内用户，所以它在功能设计，页面设计等方面都更加符合中国用户的应用习惯。 而且通过多年的倒退欠缺之后，目前WPS的性能也越来越欠缺，有很多性能甚至比office还要弱小，而且操作起来更加不便，在图表制作这方面就比拟给力，另外在云备份方面显著要比office更好用，不小心把文件弄丢了，还有可能从云备份当中找回来。 也正因为WPS更接地气，而且应用起来更加简便，所以深受宽广中国用户的认可。 2、收费是最好的营销伎俩。 目前WPS有专业版和集体免费版两种形式，对于个人用户来说，如果大家不嫌广告多，那能够下载一个收费版本装置，日常的各项性能基本上也可能用失去。 而对于中国用户来说，很多人都习惯了收费的货色，所以在WPS集体收费之后就失去了很多人的拥戴。 相对来说目前office并没有收费版本，只有一些破解版的收费，然而这些破解版的office自身就存在很多安全漏洞，很多人用了也并不安释怀。 3、拥抱挪动互联网。 最近几年WPS之所以可能疾速成长，我认为有一个很重要的起因，他们及时向挪动互联网转型。 当初很多人除了办公的时候应用电脑之外，在平时的日常生活当中，大家基本上都用手机，但即使你用手机，中国人的习惯是上班了依然会有很多工作，你不可能始终扛着一台电脑，这时候在手机上安装办公软件就成为了很多人的需要。 而且WPS也看到了这种趋势，所以很早就拥抱挪动互联网，踊跃推出了挪动版的WPS，目前WPS在移动用户的市场份额曾经十分高，所以在挪动办公需求量一直减少的背景之下，WPS的用户量也一直减少，这也间接带动了PC端的WPS装置量。 4、出于平安的思考。 日常的办公软件，尽管平时不波及什么平安事件，然而有一些重要部门的文件是十分重要的，对这种安全意识，以前大家可能没有太当回事。 但自从棱镜门事件产生之后，寰球各国对互联网安全开始越来越器重，在这种背景之下，我国也在踊跃推动互联网以及计算机国产化，包含操作系统、软件系统都踊跃进行国产化。 目前有很多重要部门的软件，基本上都是应用国内的WPS，而不是应用微软的office。 所以在多种因素影响之下，最近几年WPS的市场份额也越来越多，而office的市场份额逐步被压缩，不排除将来WPS有可能成为国内真正的办公软件头牌。 WPS有哪些“鲜为人知”的性能值得举荐？ 前不久，WPS公布了toT产品“团队办公”，让用户在WPS上除了能够应用文档演示表格这三大组件外，还能够体验如：进销存、财务管理、ERP、CRM等更多维度的办公治理利用。 而在首批上线的利用中，绝大部分都是由一家名叫 @织信 的低代码开发平台所提供的，如此疾速的响应能力，与“低代码”这门技术密不可分。 普通人对于低代码或者很生疏，但在业内，当下各大互联网巨头和投资机构都已布局其中。低代码到底是什么、又有怎么的魅力吸引这么多人关注呢？ 本期KVP洞察，WPS新潮实验室邀请了织信Informat创始人郭闫，他将从创业者的视角，分享低代码之于集体、企业、办公生态意味着什么。 口述｜郭闫（织信Informat创始人、金山办公KVP） 文｜WPS新潮实验室 1、新潮实验室: 从创业者的角度，您会如何向公众介绍低代码？ 郭闫：目前外界对于低代码的定义，是“可视化的开发方法”。 怎么了解呢？就是在低代码平台下，使用者开发软件利用，并不需要进行编程，而是依据本人的需要，选取所需功能模块，拖拽、进行参数配置，像搭积木一样，就能疾速制作出想要的软件。 从创业者的角度，我更违心将它了解为一种帮企业数字化降级降本提效的生产力工具。 2、新潮实验室: 目前低代码能够实现哪些软件的开发？您认为它带给企业最大的价值是什么? 郭闫：目前低代码次要能开发的软件以办公治理类居多，例如进销存、财务管理、资产治理、人事管理、ERP、OA、CRM、BPM、SCM等各种管理工具。 在企业，以上这些软件本来须要多个研发人员开发，抉择低代码后，人力将大大降低，业务人员甚至能够间接开发适配工作场景的软件。 所以对于企业而言，抉择低代码一来能够升高企业数字化降级老本，二来能够赋能自研能力、灵便响应各类需要。 3、新潮实验室：有没有具体的例子能够和咱们分享下？ 郭闫：这里我介绍比拟有代表性的两个案例： 公司A从事飞机设计制作，他们原有的项目管理流程零碎较为老旧，随着设施研制的一直倒退，老零碎曾经无奈承载宏大的数据量，导致业务发展艰难。 因而客户心愿建设一套以全新的我的项目管理系统来适应工作内容，并重点思考国产化适配和自主可控能力。 于是咱们与达梦、人大金仓、中科方德等国产信息化零碎进行了互认，将低代码能力传递给客户，帮忙客户把握了程序更新和迭代的能力，进行了信息化的降级。 公司B从事乳制品，在产品研发、生产制作、项目管理等方面很早就开始进行数字化转型。但因为历史起因，某些治理流程或业务未被关联，导致整体办公合作效率低下，成为企业整体数字化转型的过程短板。 例如，设施巡检治理目前仍然是通过十分传统的纸质卡片记录模式，存在巡检漏记，错记等景象。且对于公司B而言，基于原有零碎定制化拓展老本非常昂扬。 于是咱们提供了低代码的解决方案，客户采买后，以3000元老本搭建出了一套适配他们业务需要的设施巡检零碎，值得一提的是，在过程中客户也把握了低代码搭建能力，后续还陆续上线了30多个不同业务流程的信息化利用。 4、新潮实验室：除了企业，低代码的遍及对于哪些人会是利好？ 郭闫：被传统工具困扰的一线业务人群吧，再就是渴望从事低代码开发行业的求职者。 目前市场上，IT行业缺口仍旧很大，我认为将来在IT培训类目里，必定会呈现低代码培训，很多学历一般、教训个别的求职者通过培训学习，就能够帮忙企业用低代码制作这样信息管理系统，对于他们来说，能够找到的工作机会也多了。 当下和低代码相干的就业机会已有不少，当初招聘市场上低代码开发、低代码产品经理这样的新兴岗位曾经进去了，将来我预测这类岗位还会大量涌现。 还有一群很要害的人群，程序员。低代码的遍及，会帮忙一些从事简略开发工作的程序员自我增值。 曾有人认为低代码会抢走程序员的工作，但在我看来，恰恰相反，低代码能够为程序员提供更有价值的工作，并将他们从繁琐的CRUD工作中解救出来。 ...

将来的企业数字化转型，将可能围绕弹性、可持续性、自动化以及无效转型而不影响消费者的能力来发展，随着大多数企业踏上数字化之旅，软件将持续帮忙这些企业取得成功方面施展主导作用。在数字化时代，如果没有企业应用来撑持业务性能，简直很难实现业务指标。 企业应用程序是公司用来创立和执行诸如销售、营销、反对、物流和BI等业务性能的软件。从CRM零碎到计费应用程序再到ERP零碎，通常能够依据业务需要在企业的应用程序平台中进行定制。正确的工具使公司可能充分利用数据，提供自动化以进步流程效率，将各类信息数字化以缩小人工工作，并进步整体经营速度。 在以后市场环境不确定性加剧的状况下，每一个企业都应该制订一份数字化策略，定义应如何施行技术以反对业务指标并优化工作流程，从而推动企业价值晋升。大多数数字化策略打算都须要多个企业应用程序来驱动和反对。正因为如此，寻找一个更快地构建和倒退企业应用的形式，成为许多企业的重要议题。 而与企业数字化转型打算十分吻合的开发方法就是低代码。低代码开发模式是利用开发的一种可视化开发方法。通过将利用开发中所须要的繁琐业务逻辑和根底服务能力形象成一个个通用业务模型，并辅以可视化的配置开发工具，升高了非技术开发人员构建利用的难度。让业务用户在没有编程专业知识的状况下疾速起草企业解决方案的设计，不便他们用来测试和验证开发。原型设计还能够帮忙开发人员收集用户反馈，以便在整个开发过程中放弃高效的迭代。这种以用户为核心的开发方法可确保企业应用程序不仅提供价值，而且还能够补救开发周期中的设计差距。 低代码开发平台不同凡响的劣势就在于其可视化开发能力，能够在不须要编写业余代码的状况下向利用增加自定义的业务逻辑和审批流程，甚至能够通过设计器中提供的插件来实现和内部零碎的流程或数据的交互与集成。这为没有开发教训的业务人员提供了开发利用的可能性，而开发人员也同样可能在可视化开发的助力下，提供开发效率，轻松创立具备简单配置和性能的利用。低代码开发平台不仅仅成为造就混合开发团队的温床，也能大大增强部门之间的合作，来晋升效率。 同时，企业IT团队能够应用低代码开发平台进行外部利用开发，例如降级ERP、CRM等旧零碎，在这个过程下，并不会影响业务流程或被新的专有解决方案所解放。低代码是构建基于微服务的组件并将遗留代码转换为麻利应用程序的实用平台。联合基于微服务的架构能够取代遗留零碎，并实现更快的开发和更轻松的利用更新。 企业低代码利用程序开发，将在将来的几年中持续增长，随着低代码开发平台的倒退，以及自动化、人工智能等性能的加持，它们将会更加无力地帮忙企业去应答一直变动的生产需要、市场环境，以建设起更加具备弹性、适应性强的业务。

如果说在疫情之前，各行各业的数字化转型是马拉松，那么当初是就是百米冲刺了，原先可能以“3年”为单位来制订转型布局，当初变成了“3个月”。尽管从天而降的数字化百米冲刺让人倍感压力，但也让企业思变：在新常态下，通过技术更新来适应客户一直变动的需要。 在过来的一年中各行各业与公司单干的过程中，我最大的感触就是，数据真的很重要。在强烈的市场竞争中，数据当初未然成为企业实现增长——乃至保障最根本生存的要害。 约翰·斯卡利所言，其实波及到定量分析和定性分析两种不同的统计分析思路：定量分析是根据统计数据，建设数学模型，从而计算出剖析对象的各项指标及其数值的一种办法，而定性分析则是对对象性质特点的一种概括。对于商业剖析来说，两种剖析思路可没有高下之别，毕竟商业剖析最终须要的是对行业的洞见。因而，联合两者能力最终得出正当的策略。那么，对营销团队来说，该如何做好数据分析呢？上面一些须要重点关注的问题。 一、对立数据池 当初企业能获取的数据曾经是远超过往了。大家能够利用好数据这个富矿，为客户发明个性化的购物体验，塑造更强的消费者连贯。 当然，这些数据可不会俨然自在，而要业余人员来解决。有人对此专门做过测算，当下营销人员在获取数据的时候，均匀须要检索16个源——相较两年前，这个数值上涨了60%！ 数据源数量的快速增长，很大水平是因为第二方数据提供商数量的减少。 可能有人会问“第二方数据提供商”是什么，在这里做一个简略的解答：根据收集的起源，数据能够分为第一方数据、第二方数据和第三方数据。第一方数据是指企业间接从受众（包含用户、网站和App使用者、社交媒体关注者等）那里收集的数据；第二方数据是企业从其余数据原始采集者那里通过购买、置换资源所取得的数据；第三方数据是企业从内部起源购买的数据，这些数据的提供商并非数据的原始采集者。 下面提到的第二方数据提供商，正是那些向品牌提供数据以补充和丰盛品牌本身收集的数据的组织。 不同起源的数据带来了数据量的增长，而这也带来了一大问题：不同起源的数据须要进行整合，不然剖析起来就会有很多的冗余信息。然而，整合数据切实是一件耗时耗力的事件，不少企业一听见它的小名就退避三舍，这也让它顺利成了不少公司开启数字化转型的头等阻碍。更不用说开掘数据价值了。 二、数据维度 对初入数据分析的菜鸟来说，浩如烟海的数据确实会让人感到手足无措。这就须要咱们确定要关注的数据点。 这个切入的数据点据行业性质而异，就拿批发和消费品企业来说，最为重要的是理解消费者行为。从这个点登程，须要优先思考的数据，便是那些能帮忙你理解客户购买行为的数据——进一步细化，便是顾客购物习惯、趋势和偏好。围绕这些数据进行开掘和剖析，企业就能更迷信地制订策略。在诸如优化产品线、布局新SKU等方面，可能更有节奏。 仍然是批发和消费品企业的例子。在消费者行为之外，同样重要的是，要留神那些帮忙你捕获个体买家差别的数据。尽管很多企业都是服务于一个指标客户群，但即使在群体中，个体客户之间的差别仍然不小。一个经验丰富的剖析者在把握短缺的数据后，可能设计出个性化的营销计划，建设与个体用户具体而微的分割。 在抉择数据点上，上面是三个通用的切入角度，它们能让你对客户的理解更为深刻： 1、客户为什么购买：对客户购买习惯背地的动机理解得越多，就能更好地调整产品线和营销布局，从而满足客户的特定需要。 2、客户会在什么时候购买：统计学意义上，当你把握客户最有可能实现购买决策的时点，你就能进步客户最终下单的概率。 3、客户是如何购买的：关注购买形式，尽可能提供无缝的购物体验，让他们尽可能再次从你这里购买。 三、善于应用工具 数据何其重要，以至于有可能扭转你的商业模式。把握牢靠的数据，能够说跟精准无误履约订单一样重要。 然而事实是，只管品牌商取得了丰盛的用户数据，但大多数的零售商并没有为数据驱动的商业模式做好筹备。对那些曾经启动数字化转型的企业来说，这可能是件好事儿：这至多意味着他们曾经抢占了先机。 而那些还未启动数字化转型的企业，他们中的大多数可能都已晓得数据收集的重要性，但却不知从何开始。上面是一个通用的工作流：1、确定你所有的数据源；2、将所有的数据源整合到一个集中的零碎内；3、设置零碎以定期捕捉和合并数据。执行这三个步骤并非易事，然而依附正确的工具就可能最终实现。 在后疫情时代的中国，十分多企业通过企业微信的应用实现了数字化转型的，不论你是做批发、教育、金融还是其它任何行业都能够联合微盛企微管家助力企业用好企业微信做增长，基于企业微信为客户提供SaaS、征询、培训、技术开发、硬件等一站式服务，一起推动行业倒退和企业客户的数智化增长 。

古代管理学之父彼得·德鲁克讲过：“21世纪的组织，最有价值的资产是组织外部的常识工作者和他们的生产力。” 现在从美国到中国，常识治理开始被越来越多的团队和组织器重，都纷纷建设起属于本人的常识管理体系。因而，明天咱们就来聊聊企业和团队组织如何建设起本人的常识管理体系。 首先提到的是“常识管理体系的建设准则”，因为在不违反创立准则的状况下，能力创立出更好的常识管理体系。 常识管理体系的建设准则1.统筹规划，散布施行准则常识治理的施行不是久而久之，短时间内欲速不达的事件，而是一个须要长期保持的治理行为，须要整体剖析全局状况进行兼顾的布局，制订中倒退打算，依照阶段进行步骤式推动。 2.强调人的重要性，不仅仅是技术常识治理体现企业共享文化，体现企业的凝聚力，只有员工具备对企业的责任心，信念，才违心分享本人的常识，常识治理是一项全员工程，因而，要器重人，组织，制度，文化，工作习惯，他们甚至比技术因素更能决定常识治理我的项目的成败，在日常工作中逐渐建设起员工的一个良好的工作习惯。 3.常识治理融入理论业务流程只有将常识治理固化到业务流程中，能力保障施行常识治理不是一项“短暂的静止”，而是一项长期的制度，能力放弃长期运行上来。在业务流程中，员工要建设起首先查问知识库的意识，而后再进行业务操作的工作习惯，在业务流程中的重要环节激励留下操作记录，并由相干人员评审，对好的记录进入知识库。 4.强调常识的考核和评估常识治理同其它的企业治理一样，除了须要侧面的推动，奖励制度，更须要建设常识的考核和评估制度，首先明确各部门，各岗位产生哪些常识，更新周期，更新工夫，共享要求，下达常识治理工作，考核常识治理工作的执行状况。 探讨完常识管理体系的创立准则后就要进入明天的正题了：如何创立高效实用的常识管理体系？ 如何创立常识管理体系咱们能够先建设本人的“知识库”，相似于呼叫核心的“知识库”。呼叫核心的“知识库”更像是一个搜索引擎，只有搜寻关键字，就能够查问相干的问题及答案，所以咱们能够借用创立知识库的软件来欠缺咱们的“知识库”，相干工具能够辅助咱们更直观、清晰、明了的对待这些信息。 有了辅助工具当前，咱们就能够开始“五步走”：收集、整顿、转化、分割、反馈。 1. 收集先收集对企业和团队有价值、有帮忙，或是新鲜的信息，获取这些信息渠道也很多，例如：会议、文件材料、行业资讯……将这些信息搁置“收集”这一栏。 2. 整顿紧接着，确定一个具体的工夫，安顿人员定时整顿收集的信息。按内容将信息进行分类，例如：工作教训、工作办法、应用工具等等……就像整顿一间脏乱的房子，将物品归位，衣服挂在衣橱、鞋子放在鞋柜、洗漱用品放在洗手台上。例如：我看到一篇文章写治理团队TOPIC模型，我觉着这内容很实用，于是我将文章的一些中心思想总结后放入“培训——通用课件——团队治理”这一栏，并附上文章的链接。 3. 转化整顿好当前，就须要将有用的信息转化为常识，测验是否转化最无效的的办法就是“实际”。比方总结的一些会议的办法，能够应用看看是否可能进步会议效率，让“有效的会议”变得越来越少。或者是一些工作教训的应用，这对于新员工有很大的帮忙。再讲一个耳闻能详的“费曼技巧”，其外围在于想像本人是一个老师，正在教一个学生。还是治理团队TOPIC模型的例子：在讲之前，咱们须要先学习什么是“TOPIC模型”；当你认为本人学习的差不多的时候，你设想下如果是面对一个没有任何治理团队根底的人，你是否能够向他解释分明“TOPIC模型”作用及使用。如果你发现在解说当中，你依然存在一些盲点，那你能够从新回到第一步找找答案，再重新学习一遍，查漏补缺；再反复第2步，尝试着用更简洁的语言或类比技巧去解说“TOPIC模型”作用及使用，当你能够十分自若的且不假思索地讲出“TOPIC模型”作用及使用，那么你就曾经把握了它。以上就是“费曼技巧”，用本人的语言来解说本人想要学习的内容。 4. 分割信息转化后，它就不再是信息而是常识！更深刻的一步是“分割”。在新常识和旧常识之间建设“分割”，达到常识的死记硬背，从而建设本人的常识管理体系。它们之间的分割都是对大指标进行合成及治理。 5. 反馈最初就是反馈了，转化与分割不是止于一次，而是屡次。如果能够获取一些使用者的反馈，那么对咱们的帮忙是非常大的。这个使用者既包含外部员工，又包含内部用户，他们的反馈都有很大的作用，可能及时对知识库进行调整、优化，不断完善知识库。 借助工具以上讲到了常识管理体系的创立准则与创立办法，也提到了须要应用肯定的常识管理工具来辅助创立，那么在这里就给大家举荐一个常识管理体系的创立软件，Baklib。 Baklib可能作为一款常识管理软件，可能帮助企业进行常识治理，并且通过零碎的常识管理体系，缩小企业对员工的培训老本、劳动工夫老本，进步工作效率，从而加强企业的竞争能力。 四步创立知识库： 根据目前的局势，对于企业和团队来说，搭建常识管理体系迫不及待，否则将会落后于行业或者你的竞争对手。如果你还没有进行常识治理，那还不赶快动起来。

设施治理是企业生产经营流动的重要环节，企业生产过程环环相扣，设施运行状况好坏，不仅间接影响到企业的生产效率、产品质量和成本费用，而且危及到重大设施损坏、人员伤亡等隐患。所以，做好设施的高效治理、保障设施稳固运行至关重要，是企业做好降本增效的根底。目前，大多数企业在设施治理中都面临着巡检效率低、流程不标准、数据统计难等如下问题： 传统的巡更巡检办法都是靠人工拿着记录本进行设施巡检,查看过程耗时长，设施呈现问题的记录也不利于后续查阅、跟进复检和及时解决，无奈及时理解到设施运行状况。人工记录巡检后果，随便涂改，页面不整洁，影响查看。每个人字迹不一，也会影响查看。影响到巡检的后果判断。巡检工作治理的传统执行方法是采纳纸质表单签到或应用巡更棒巡逻打点实现。巡检人员没有准时到位的状况时常产生，还会呈现找人代签而逃班的状况。设施多且都是同一型号设施，巡检人员漏检状况就会产生。同一时间多个巡检人员在不同区域进行巡检，管理人员不能够跟着每个人，不能无效把握到巡检人员的工作状态。对巡检人员不足监督。巡检的记录数据难以集中，不能很好地对巡检数据进行剖析和查问。巡检没有打算，没有优先布局好最优巡检线路，巡检人员不晓得要巡检什么设施。企业的生产设施繁多，易发故障比拟多，手工统计解决麻烦。企业该如何解决设施巡检治理中呈现的种种问题？应用白码低代码开发平台的设施巡检管理系统就能解决并大大晋升巡检效率。设施巡检管理系统实现多部门协同互通治理设施巡检工作，晋升设施管理效率。它能通过巡检数据将设施的运行状态反映进去，通过收集、存储和分类后，及时地将设施的技术情况及运行状态等示意进去。设施巡检管理系统将每次巡检中的设施运行状态和监测数据等，全副记录在管理系统中，既平安又便于管理。借助设施巡检管理系统可充分利用巡检数据分析来帮忙解决设施运行保护工作。设施巡检管理系统实现了设施运行的动态化治理，进步了设施劣化趋势的可控性治理。放慢了设施信息的收集、整顿和反馈速度，升高了巡检员的工作量，进步工作效率。及时把握最佳的检修机会杜绝了故障酿成了重大设施事变的产生，也进步了设施运行率。

个别公司的资产能够分为两大类，别离是固定资产和个别易耗品，个别易耗品都是指价值绝对较小，且容易被耗费的物品，例如笔墨纸砚等等，而固定资产个别都是价值绝对较高，且不易耗费，个别都是设施类，如电脑、服务器、空调、多媒体等，价格较高。随着企业的一直倒退，所领有的固定资产品种和数量越来越多，大部分企业也没有对固定资产治理器重，就会呈现有以下的多种问题。 固定资产购入后，没有全生命周期的治理，只有纸质的档案记录。在理论的固定资产流转过程中，应用人和固定资产信息并不对应。账、卡、物不统一。资产治理不够集中，不足兼顾的流程治理。资产凌乱，没人能精确把握企业资产状态。例如资产（办公用品、生产设施、工具等）有多少？在哪里？谁用着？好的还是坏的？剩多少？缺多少？无奈责任到人。没有成熟的固定资产管理制度，不足信息化治理，资产不明确，固定资产调拨和调配不合理，造成资产反复购买与资产不足并存。资产盘点环节简单，盘点工作量大，耗时长，还会呈现人员盘点不认真，搪塞盘点的状态，准确率不高。企业外部资产占用，如果企业有多个上司公司，容易造成固定资产在各公司之间相互占用，日常治理和盘点都非常复杂。固定资产财务帐目与实物资产对不上，个别财务要求只有肯定价值之上的资产才入财务帐目，但理论治理中须要治理许多不太值钱的物品，导致财务账面的固定资产和行政治理的实物资产对不上。企业固定资产治理老本很高，大部分企业还是应用Excel来治理资产，繁琐还容易出错。大规模的固定资产投资往往消耗了企业的大量资金，而投资的发出又须要新投资的固定资产在应用中扩充生产能量，增加收入来实现。固定资产利用状况好坏决定了企业投资的发出状况。固定资产管理水平的滞后以致先进的固定资产配备无奈充分利用，影响了企业生产效力的施展，也妨碍了企业的进一步倒退，企业必须要器重。该如何解决资产治理问题呢？一个零碎就能帮到你，应用白码低代码开发平台的资产管理系统。资产管理系统能线上分类记录资产信息，规范化治理，落实到应用人、所在部门。对资产出入库信息具体记录治理，应用人可发动领用，借用，退还。可设置自定义审批流进行单据的审批，让流程更加顺畅。最初应用人进行收货签字。让责任更加清晰。 资产全生命周期治理，从资产领用人、偿还日期、资产培修、资产作废、都能够进行审核，资产信息高深莫测。提供多种盘点形式，容许手工盘点，手机扫码盘点，全员盘点。数据在零碎中随时有迹可查，齐全去纸化。自动更新资产最新状态，随时能留意到资产去向和资产数目状况。如果您感兴趣，白码的软件核心有多种行业类型的企业经营管理系统收费试用，你能够间接对资产管理系统实操体验一下。资产治理是财务的无效延长。管好公司的每一个资产，用好每一个资产能够帮忙企业节约大量现金流，发明大量利润。应用资产管理系统进步企业工作效率，加重行政和财政部门工作，节约工夫和人工成本，做到资产实时监控，正当调配，无效利用。

实验室信息管理系统(LIMS)是一个围绕样本集中数据库构建的平台。LIMS解决方案以数字形式记录和跟踪与实验室样本相干的数据、后果、工作流程和仪器。实验室应用LIMS来放弃合乎最高规范并简化其实验室流程以提高效率。 什么是实验室lims零碎？实验室应用实验室信息管理系统(LIMS)统一地记录、跟踪、记录和报告样本和迷信数据。只管与质量保证和品质管制过程相干的测试能力随着技术的倒退而倒退，但实验室lims零碎的次要性能放弃不变：实验室须要在整个过程中审核样品，从创立到公布、应用和处理。实验室lims零碎提供准确的跟踪级别，帮忙实验室遵循行业最佳实际。零碎会自动记录某些数据，缩小记录样本的人工工夫，并有更多工夫优化流程以提高效率和准确性，从而取得更牢靠的后果。理解实验室lims零碎意味着牢记以下注意事项：统一的样品治理既辣手又耗时。如果没有实验室lims零碎，实验室工作人员将手动记录样品并应用他们本人的命名约定。这种做法不仅耗时，而且意味着存在很大的人为谬误空间。实验室lims零碎通过条码和统一的命名约定利用数字跟踪帮忙打消这些谬误。数字集成能够改良文档和实验室工作流程。许多实验室lims零碎解决方案能够与实验室硬件集成或连贯，以导入样本详细信息或导出样本数据，无论是用于存储还是间接进入其余应用程序进行进一步剖析。实验室lims零碎解决方案还能够从测试或试验运行中辨认谬误，甚至在必要时适当地标记它们。执行主动报告并取得对样本数据的可见性。因为样品从创立到处理的生命周期齐全通明，实验室lims零碎能够拜访报告和审计所需的数据，并确保品质管制。放弃整个实验室的数据完整性。如果没有实验室lims零碎，实验室对手动文档的依赖会变得繁琐且容易出错，尤其是在实验室规模扩充且一起测试的样本数量减少的状况下。这种增长尤其产生在具备宽泛管制和大量剖析复制的测试环境中。 实验室应用实验室lims零碎做什么？以下是实验室的指标，施行实验室lims零碎能够帮忙他们实现目标并满足他们的日常需要。样品治理实验室须要记录、跟踪和治理与管制和样本相干的库存。实验室lims零碎能够帮忙科学家在须要时取得他们须要的货色，并缩小手动数据输出可能带来的人为谬误的工夫和偏向。批次治理和公布领有实验室lims零碎能够监控批次应用状况和批次性能。它还能够跟踪实验室成员之间的批次散布。对于以前的相似批次，零碎会提供这些数据，以便能够在整个产品的背景下进行剖析，而不仅仅是单个批次。稳定性钻研治理科学家能够配置他们的样本库存并钻研在不同温度和湿度下存储的影响，跟踪样本是否通过适当和正确的测试，并通过数据趋势避免将来进化。这些长期钻研波及开发一个已有多年历史的简单测试矩阵。环境监测实验室能够应用LIMS查看批量生产的品质或整个调配零碎的水品质。该零碎为每个样品提供了牢靠的可追溯性，这些样品可能会受到无害细菌检测或品质不当的影响。外部报告因为其自动记录，实验室lims零碎提供可搜寻的审计跟踪，精确记录样品的存储、它们的耗费、后果和随后的数据分析。客户报告实验室lims零碎以其残缺的文档提供了高度的透明度。这为须要报告的第三方审计和客户提供了价值。最小化资源耗费实验室能够最大限度地缩小记录样本的工夫，并花更多的工夫在理论工作和剖析上。所有样本的数字记录能够节俭试图追踪或潜在地从新生成必要样本的工夫和金钱。

CRM是任何企业的重要组成部分。 就其外围而言，客户关系治理(CRM)是公司用来治理与以后和潜在客户的交互的所有流动、策略和技术。 许多企业常常听到和说的一句话是“客户为王”。 CRM可帮忙企业与客户建设关系，从而建设忠诚度和客户保留率。因为客户忠诚度和支出都是影响公司支出的起因，因而CRM是一种能够减少企业利润的管理策略。crm的外围是创立一个简略的用户界面来收集数据，帮忙公司以可扩大的形式辨认客户并与客户进行沟通。企业治理与客户的关系越好，它就会越胜利。因而，专门解决日常与客户打交道的问题的IT零碎越来越受欢迎。客户关系治理(CRM)不仅仅是技术的利用。尽管如此，它还是一种策略，能够更多地理解客户的需要和行为，以建设更牢固的关系。因而，帮忙无效和高效地与客户打交道的更多是一种商业理念，而不是一种技术解决方案。然而，胜利的CRM依赖于技术的应用。 crm的外围是什么？CRM对企业的核心作用是什么？无效治理客户生命周期从营销到销售再到服务——对贵公司的盈利能力和增长至关重要。这就是为什么许多公司发现为其业务抉择客户关系治理(CRM)零碎的外围价值所在。然而，很多人不晓得的是，CRM零碎能够不仅仅是捕捉帐户和联系人数据的根本销售人员自动化工具。进步营销效率并最大化营销收入借助CRM解决方案，您能够通过为营销业余人员提供灵便的细分工具、简化的流动治理性能、直观的响应跟踪和富裕洞察力的剖析来进步营销效率。这可能会导致充斥合格潜在客户的渠道减少。领有用于治理和跟踪从潜在客户到完结的多渠道营销流动的繁多零碎，您能够轻松创立仪表板和报告，以查看您的哪些营销工作带来了最多的销售额。CRM解决方案使您可能展现营销对组织的影响，并让您开始对最适宜您业务的策略和策略进行再投资。帮忙销售人员提醒销售额所有CRM零碎都可能建设残缺的客户历史记录，从而进步销售效率。这使销售人员可能专一于将机会转化为封闭式业务，只需一个中央即可更新交易信息、记录客户互动、跟踪竞争对手和创立报价。您的CRM零碎应该使您的团队不仅可能找到他们须要的信息和历史记录，而且还容许他们执行预测和客户打算流动，例如合同续签和销售降级等。通过在CRM中增强您的销售流程，销售代表将取得一种卓有成效的办法来治理和实现交易。此外，CRM零碎将使销售人员和经理可能理解交易并确定其销售工夫的优先级，从而使他们可能更快地实现正确的交易并减少交易额。该零碎还通过自动化工作流程和审批打消了繁琐的治理工作。最初，CRM零碎将使您的销售经理可能创立所有权和问责制，并通过跟踪所有销售代表流动进行监督。用心服务打造一生客户当交易实现时，您的CRM零碎不会进行。持续应用CRM的服务模块为您的客户服务和技术支持团队构建360度客户视图。应用可简化案例治理、简化上报、改良常识共享和实现更无效帐户治理的工具为您的员工提供反对。这些工具和流程的后果将帮忙您的组织在不就义服务质量的状况下管制服务老本。事实上，您的客户会对服务人员感到高兴，他们领有所有客户历史记录和无效解决问题所需的知识库。 为什么要施行CRM解决方案？CRM解决方案通过简化销售、营销和服务部门的治理流程，让您专一于建设和保护重要的客户关系，从而进步您的盈利能力。弱小的CRM解决方案是一个多方面的平台，其中存储了对开发、改良和保留客户关系至关重要的所有内容。如果没有集成CRM解决方案的反对，您可能会错过增长机会并损失支出，因为您没有优化经营流程或充分利用您的客户关系或销售线索。设想一下，错放了客户分割信息，却发现您的提早导致客户被竞争对手抢走。或者，设想一下你的前两名销售人员同时分割雷同的潜在客户，后果导致潜在客户恼火和一些不敌对的外部竞争。如果没有集中和自动化的CRM零碎，您的员工可能会失去对客户互动的跟踪并错过商机。 CRM的商业利益施行客户关系治理(CRM)解决方案可能须要大量工夫和费用。然而，有许多潜在的益处。与现有客户建设更好的关系是一个显着的益处，这可能会导致：因为依据历史趋势预测需要，通过更好的机会减少销售额通过理解特定的客户要求更无效地确定需要通过突出和倡议替代品或加强性能来穿插销售其余产品确定哪些客户是有利可图的，哪些不是这能够通过关注以下方面来更好地营销您的产品或服务：专门针对客户需要的无效有针对性的营销流传更个性化的办法以及开发新的或改良的产品和服务，以在将来博得更多业务最终这可能导致：进步客户满意度和保留率，确保您在市场上的良好名誉持续增长减少现有客户的价值并升高与反对和服务相干的老本，从而进步整体效率并升高总销售老本通过专一于最有利可图的客户并以更具老本效益的形式解决无利可图的客户来进步盈利能力一旦您的企业开始无效地关照现有客户，就能够将精力集中在寻找新客户和扩充市场上。然而，同样，您对客户的理解越多，就越容易辨认新的潜在客户并减少您的客户群。即便积攒了多年的常识，也总有改良的余地。客户需要随着工夫的推移而变动，技术能够更轻松地理解更多对于客户的信息，并确保组织中的每个人都能够利用这些信息。

前言随着技术的暴发，企业对于云化也有了更高的要求。将来只有构建原生为云而设计的利用，能力以最佳姿势在云上倒退，充分利用和施展云平台的弹性和分布式劣势。 因而，作为云计算的下一站，云原生在重构IT架构的同时，也为更多畛域开释了新的技术红利与增长时机。正如文中提到的中国一汽和三一团体等大型企业，正是在数智化转型的攻坚期利用云原生技术实现实质性冲破。 用友作为最早布局云原生架构的企业之一，以iuap技术平台为依靠，在帮忙企业高效享受云的弹性和灵活性的同时，撑持企业业务疾速翻新和倒退。 1、用友iuap技术平台，开释云原生架构红利让传统企业充沛享有云原生带来的技术红利，赋能企业实现云原生自在，是YonBIP用友商业翻新平台的必经之路，也是企业数智化转型冲破瓶颈的要害之举。 为此，作为YonBIP的PaaS底座，iuap从基础设施层面着手， 从底层搭建了可晋升云原生架构能力的技术平台，通过简单化、通俗化、大众化的各类型工具，提供企业运行稳固、架构灵便的技术撑持。 iuap服务于成长型、大型及巨型企业数智化转型，助力企业晋升数字化技术驾驭能力。iuap提供凋谢共享的生态连贯，赋能客户、生态搭档、社会，共享共创，成就数智企业，推动商业翻新。 iuap技术平台将DevOps理念转化为实际，基于kubernetes、Docker、 ServiceMesh等技术，为用友及生态搭档提供开发、集成、监控、服务治理等PaaS服务，让YonBIP PaaS平台更具弹性、服务更便捷。 同时，作为集容器云、DevOps、服务治理、Hubble链路追踪、分布式系统事务一致性、测试与运维工具于一体的综合技术撑持与治理平台，iuap技术平台反对业务疾速翻新。企业能够疾速部署业务利用，动静调整业务利用的资源环境，晋升从需要到产品的生产效率，让业务利用极速施展价值。 区别于其余云原生技术厂商，用友的最大劣势在于深度联合企业应用场景，构建标准化的产品和利用，以最便捷的形式实现云原生的技术赋能，疾速响应业务的实时需要。应用技术平台上的各类云原生工具进行开发，让开发人员交付的产品人造就是云原生利用，使业务与最新技术趋势完满交融。 例如运维监控，如果采纳纯原生的技术开发，技术人员须要把握多种技能，编写很多代码。然而，通过技术平台上的监控服务，用友将图形化的产品间接提供给企业。他们只须要配置接口后就能够应用了。这就是YonBIP在技术赋能方面更简略、更便捷、更大众化的意义所在。 以后，各行业畛域基于云原生进行的数字化转型实际不断深入推动，越来越多的企业抉择iuap摸索业务翻新与治理改革，而用友也通过iuap的大量客户云原生落地实际造成了无效的中台建设方法论，能够帮忙客户无效的管制我的项目建设危险及老本。 2、激活技术动能，磅礴翻新能源一个具备市场竞争力和可继续倒退的技术平台，其架构应该是持重的，岂但能够很好的撑持业务倒退，而且须要从各行各业中提取技术研发的共性，打造通用型产品。其中，可能适配或笼罩IaaS层的各类私有云、公有云、混合云，撑持更宽泛的业务应用场景，是技术平台的根底能力之一。 用友iuap技术平台底层的多云适配器，将不同的基础设施云厂商提供的对外接口整顿、形象、对立封装，通过一系列根本属性和通用操作，造成容器云跨云适配、微服务框架多云适配、监控服务多云适配和根底技术组件多云适配，让多云交融的基础设施更好地服务业务。 而随着越来越多的企业把业务迁徙上云，云中间件作为一个连接器，起着承前启后的作用。它不仅让下层业务对上层数据库的架构更加通明，而且更好地将架构及节点关系暗藏起来，让业务享受无感知的云服务。 为此，用友iuap技术平台的YMS云中间件能够解决资源层适配的问题，与不同的数据库如达梦、人大进仓、华为云数据库买通，将具体业务和底层逻辑解耦，全面解决企业在上云过程中对于数据库的技术需要，从而更好地承接业务申请。 家喻户晓，微服务架构由一系列绝对独立、细粒度的服务组成，在一个残缺的业务逻辑调用申请背地，可能波及后端几十个甚至上百个服务接口，而每个服务可能是由不同团队开发，应用了不同的编程语言，或是散布在不同的数据中心。因而，对于这样一个简单的逻辑调用关系，如果在调用过程中产生问题，开发人员如何疾速定位，如何判断故障影响范畴，如何剖析链路性能和实时容量布局，如何残缺还原一次申请的链路状况？ 为此，用友构建了微服务架构下的全链路监控体系。借助微服务治理和Hubble全链路监控，能够从整体维度到部分维度展现各项性能指标，将跨利用的所有调用链性能信息集中展示，不便度量整体和部分性能。 同时，Hubble全链路监控还提供了业务流转的录制性能，通过数据埋点、传递、收集、存储等伎俩，将一次分布式申请还原成调用链路并造成报告，不便技术人员剖析业务链路的调用状况，并通过过程信息疾速定位故障产生的源头，通过消息日志查看具体的错误信息，从而极大地缩短故障排除工夫。 试问什么办法能保障高质量的前提下，缩短零碎变更从提交到部署至生产环境的工夫，并能够继续集成和交付？那肯定是DevOps。其自动化、可视化、流水线式的工作形式，岂但能够晋升利用交付的品质和速度，还能够依据不同的业务特色制订不同的流水线。 用友iuap技术平台中的DevOps利用治理和通用技术组件服务，基于麻利开发的核心思想，让企业内小而自治的技术团队可能借助自动化部署、智能化交付的流水线服务，疾速响应频繁的业务变动和产品迭代，使业务需要疾速转化为线上生产力，从而驱动业务人员和技术人员将次要精力投入到业务翻新中去。 值得注意的是，在用友iuap技术平台整体架构中，AIoT智能物联网平台和区块链平台作为根底技术服务，也被列入其中。AIoT 物联平台是用友在物联网畛域公布的根底能力平台，可便捷实现OT-IT交融，让工业数据谈话，实现数据驱动智能工业，助力企业商业翻新。 而为了升高企业经营老本，提供更平安的经营环境，满足业务的伸缩性，用友iuap技术平台通过提供区块链平台，帮忙中大型企业，尤其是央企客户贯彻落实区块链国家策略，疾速部署区块链技术，升高他们的应用门槛，屏蔽简单的底层技术细节，使用户专一于业务利用和场景翻新。 3、煊赫数据背地的神奇力量目前，iuap技术平台曾经能够撑持用友外部业务大规模公布工作。其中，线上容器数量多达9600个，流水线构建次数超过102万次，微服务注册利用5000余个，API数量已超过30万个，应用的技术人员超过36000人，每天服务调用数超过3.5亿次。 针对各类场景检测的数据显示，仅YonSuite一个私有云平台在用友iuap技术平台每天构建次数超过2346次，撑持DevOps流水线公布67万余次，迭代上线的服务近2300个，并实现迭代测试16万余次，联调测试31.8万余次，预发公布8万次，生产环境测试3.2万次，以弹性稳固的云服务满足成长型企业商业翻新。 同时，用友以iuap技术平台能够帮忙企业全面上云、一键迁云。汇合了百余个微服务的云产品可在2小时内撑持企业业务疾速出盘，最大化确保生产环境不受影响，达到业务无感知。 用友iuap技术平台岂但激发了用友及生态的内生力量，同时还打造了不少企业数智化转型的标杆。 中国一汽的将来指标是构建数字孪生平台，做一家一流的出行服务公司。做出行服务就意味着IT架构全面生产互联网化，服务、产品、协同模式都要改革，这时候只有云原生的微服务架构能力造成真正的敏态。 一汽启明对所有的开源厂商都有深入研究，通过谨慎的选型与评估，高度认可用友YonBIP的设计理念。因而，基于iuap打造国内汽车行业外围数智化平台。一汽的数智化平台次要实现四个要害价值：重构数字化底座，建设一汽100多个子公司不同零碎之间的泛在连贯，凋谢架构构建凋谢的数字生态，建设一汽的数字孪生，构建数据化能力。 三一团体有限公司，遇到了自动化洽购执行不现实、前瞻性供应商治理有余等问题。 通过用友iuap构建寰球供应商平台后，显著降低成本，晋升开发效率，人员老本缩小35%以上，开发效率晋升40%；平台化撑持提供对立友好用户体验；胜利降级为具备弹性伸缩的微服务架构；帮忙企业更好的聚焦于业务自身，疾速应答业务变动。本来开发人员大量的须要关注框架开发、底层运维等底层技术问题，当初全副由平台解决。例如，解决收货单的散布锁，本来一周的工作量，当初几行代码解决。 作为传统家居品牌，全友家居为了投合80后、90后支流生产人群，利用双11购物节，实现了一场由内而外的，从产品、体验到营销的大促。而汇流巅峰的背地，正是用友iuap技术平台的弱小撑持。 为了可能打赢这场硬仗，全友家居构建了多渠道、多触点的数字化营销中台，对立解决订单、库存、结算和物流等业务。基于用友iuap技术平台，他们打造了一个近80台服务器的弹性计算平台，将营销业务容器化，通过360个Docker实例，集中处理了近21万个订单，实现了双11当天10亿元的销售指标。 在全国人民和衷共济抗击疫情的关键时刻，用友也积极参与到数智战“疫”进行时，用友区块链团队施展用友数智化平台能力劣势，建设了基于区块链技术，凋谢、共享、实时、通明、可信的公益捐献社会化公益服务，帮忙公益组织进步公益治理透明度、公益流程效率、信息可信度和危险控制能力。 同时，用友向中国红十字会捐献的区块链服务，紧密结合中国红十字会捐献业务管理改革须要，实现捐献业务上全笼罩、数据上全共享、流程上互相连接对立、治理上协调一体化的红十字会数字化经营平台，实现捐献的高效运行与信息的通明公开，进步业务管理的先进性和信息透明度，助力中国红十字会高效通明的社会化沟通。 由此可见，用友iuap技术平台基于煊赫一时的云原生架构，曾经成为企业上云的最佳门路。如果说极致的弹性能力、故障定位能力及大规模复制能力是它的技术劣势，那么将异构资源标准化，减速企业基础设施降级等能力，则代表了它在云架构下对企业数智化商业翻新利用的实用价值。而从产业交融最前沿数智化技术角度来看，用友iuap技术平台逐渐在区块链、物联网等畛域锋芒毕露，也成为它独特的劣势所在。 国内的云原生市场方兴未艾。从产业交融到商业翻新，从技术场景到利用落地，这些还都处于继续的摸索和翻新阶段。而随着企业数智化商业翻新需要日渐旺盛，用友的数智化技术底座是否能真正经得住企业的继续考验呢？让咱们刮目相待，兴许还有更多行业实际期待咱们的深刻开掘。

一、企业数字化转型到底是什么？数字化转型（Digital transformation）是建设在数字化转换（Digitization）、数字化降级（Digitalization）根底上， 进一步涉及公司外围业务，以新建一种商业模式为指标的高层次转型。数字化转型Digital transformation是开发数字化技术及反对能力以新建一个富裕生机的数字化商业模式。 数字化转型表明，只有企业对其业务进行系统性、彻底的（或重大和齐全的）从新定义——而不仅仅是IT，而是对组织流动、流程、业务模式和员工能力的方方面面进行从新定义的时候，胜利才会得以实现。 为了不便了解，我将企业数字化转型分为两个阶段给大家解说： （1）数据不是资产 第一阶段的企业数字化转型大都是从洽购、生产、治理、销售等具体场景进行的数字化，让所有流程都能比拟清晰地出现并治理，这个阶段次要是引入各种ERP、CRM、OA、BPM财务管理等等办公零碎利用。有了这些软件的引入，对于许多传统企业来讲的确是一个原子弹般的大杀器，用得好能够晋升效率，降低成本。该阶段对于传统企业也比拟好了解，引入这些软件之后，基本上很多问题都能够迎刃而解了。 （2）数据是企业数字化转型的外围局部 等到了企业数字化转型外围局部，很多外部事件会发生变化。所以数据的变得越来越重要，也有人认为“数据是企业最重要的外围局部”这样的说法。数据还是那个数据，只是因为数据能够在大数据技术突飞猛进之后，能够失去无效的利用，能够利用数据进行智能化思考、决策，整个商业的底层逻辑在扭转，企业不进行数字化转型，将来可能是和“机器企业”在肉搏，后果可想而知。 二、企业数字化转型3大难点？（可能你也会遇到）在咱们曾经晓得企业数字化转型重要两个阶段之后，企业在数字化转型中或多或少都会遇到一些问题，上面顺便也给大家科普一下。 下面讲到，企业履行数字化转型，会引入ERP、CRM、OA、BPM、财务管理等等办公零碎利用，这些软件将扭转了原有企业传统老化的纸质甚至是口头流程，而用更加智能化、数字化的形式，缩减了其中的工作流转，进步了团队协同效率。 而办公零碎在我国曾经有将近20年的倒退历史了。很多的畛域也诞生了许多优良的软件。然而企业在进行数字化转型的落地的过程中，零碎的部署、推广、利用依然存在着微小的问题。让很多的企业深受困扰，明天咱们就来讨论一下，到底呈现了哪些妨碍。咱们又该如何冲破。 （1）洽购 or 开发 ？都是一笔昂扬的费用。 企业为了可能疾速地进步本人的外部治理能力从而洽购市面上支流的管理软件来推广应用。这个动作看似没有问题，然而却隐患重重。 第一、往往成型的软件系统，洽购都在十几万甚至上百万的区间，如果短期内没有实现效益，无形之中大大增加了企业的经营老本。 第二、本人研发意味着要组建技术团队，然而产品的完成度，齐全依赖于技术团队的教训，当下想要从零做起搭建一个企业级的管理系统利用，所破费的工夫和金钱老本也不低。 （2）员工抵制？用推广总是遇到妨碍 一款成熟的软件如果须要在全公司推广，若公司之前没有欠缺的管理体系，须要从新自上而下的部署推广，那么无论是会存在很长时间的磨合期，这个过程中，也可能随同着员工的冲突或者是新老业务流程抵触的问题。往往很多企业几十万洽购来的零碎，在这一个阶段，只能忍痛放弃。 （3）产品固化！难以拓展延长缓缓被淘汰 办公零碎的更新换代是十分困难的，然而目前各行各业的倒退步调越来越快，新的业务流程，新的产品状态，新的管理模式，都在井喷式的呈现，管理系统如果跟不上时代的步调便会脱节，然而如果你的团队没有强有力的技术撑持那么这套零碎就没方法与时俱进的更新换代。 三、企业数字化转型解决方案！面对这样的状况下，咱们该如何寻求新的冲破，走好企业数字化转型之路呢？ 举荐管理者们应该去理解一下低/零代码平台。 这是一种能够疾速联合企业理论业务场景，来量身搭建企业管理系统利用的定制化零碎。 企业不再须要依赖于程序员或者是业余的软件企业。而是能够完完全全依附本人的业务或者管理人员，来创立出本人所想要的利用，并且能够随时的更新优化。 织信是这样一款高度自定义是企业信息化零碎构建平台，可能依据企业及团队的需要，低成本高效率地帮忙管理者搭建一站式的企业治理平台。成为开启数字化转型的重要引擎。 织信低/零代码平台的可能帮忙企业辞别高老本低效率的传统开发时代。 大幅度提高企业业务零碎的开发效率齐全解除对IT人员的依赖懂业务即可搭建零碎垂直式升高企业经营老本实现让数据驱动治理正当并且无效地使用低/零代码平台，不仅能够让咱们工作高效地运行，还能最大水平保障团队指标的达成。我举荐应用织信Informat，它内置100多个利用模板并笼罩：OA、ERP、CRM、绩效、人事、企业服务、集体及组织等多个利用场景。点击一键装置，即可收费试用。当初注册可享受一生收费应用权利。同时还能体验在线搭建性能，是帮忙企业开启数字化转型的重要引擎！

之前看到有人问，有没有对于“传统制作企业数字化转型的常见问题及解决方案”的内容，明天织信就从四个方面来答复这个问题：传统制造业是怎么的、传统制造业的痛点、传统制造业数字化转型的常见问题、数字化转型门路示例。 一、传统的制造业是怎么的？ 政府、企业、服务商都在谈传统制造业转型降级，那么传统制造业到底是怎么的？咱们有多少传统制造业企业？为了放大咱们明天探讨的话题，我给一个绝对狭窄的定义：传统制造业是指企业用传统的生产方式生产产品。有一些很先进的产品，比方：智能扫地机器人，可能它的生产方式是十分传统的，由流水线上大量的工人拆卸生产。还有一些寰球知名品牌，产品由国内代工厂生产，大量人工来拆卸，这种情景在制造业里十分广泛。 在一些大型团体里，可能有几个工厂做得很好，建立了数字化转型标杆，但可能依然有一些工厂还保留着传统的生产方式：现场凌乱、没有精益的痕迹、生产环境绝对顽劣、生产效率较低。 二、传统制造业的痛点？ 传统制造业有各种各样的问题，每家企业的问题也各不相同。上面跟大家分享几个我看到的痛点： 1、工厂里的生产设施比拟传统老旧，无奈提供数据接口； 2、产品由人工来测验品质，测验效率较低且品质值得狐疑； 3、人工进行产品装箱，常常少放、漏放，受到客户投诉，影响企业信用； 4、生产人员大量工夫放在解决间接工作上，造成无效生产工时的节约。 这些问题会促使企业的管理层思考应该该用何种形式来解决。 三、传统制造业数字化转型的常见问题 数字化伎俩可能帮忙企业管理者很好地解决企业的一些痛点，但如果之前没有很好地应用过数字化零碎，在开始思考数字化转型时很可能会产生一个问题，上面是传统制造业数字化转型的常见问题及倡议。 1、问题（数字化转型大而全） 企业在做数字化转型时，经常会一开始就做大而全的计划布局，但真正去做的时候会发现想得太美妙。数字化的伎俩很可能会把问题变得复杂化，岂但没有解决问题，反而带来了新的治理问题。特地是一些刚刚开始筹备做数字化转型的传统制作企业，不应该去做大而全的布局，应该从小处着眼，定点解决一些问题。很多企业一上来就心愿有一个很好的解决方案，然而，如果企业根底工作没有筹备好，治理能力没有跟上，解决方案工具给到企业也达不成想要的指标。 2、倡议 （1）由外而内企业有客户，有供应商，也有外部的治理，我认为传统制造业首先应该解决对外的数字化利用。有一家给寰球巨头企业供给金属构件的工厂，拿下订单后交期大略有三个月，这些寰球巨头会定期去跟供应商理解订单信息，原材料买好了没有？有没有开始入库？有没有开始切割？有没有开始焊接？有没有筹备好能够发货了？这当中每一句话，每一个问题，都代表着不信赖。 这家企业为了解决这个问题，开发了一个小小的订单管理系统，把订单的状态信息录进零碎里，而后把这个零碎凋谢给客户，客户就可能随时随地看到订单的状态和变动。这个小小的零碎不仅拉近了和客户之间的信赖关系，还很大地晋升了后续取得订单的能力。 内部的合作比拟容易带给企业的管理者，特地是传统制造业的管理者，在数字化转型方面的信念。外部能够临时先用手工的形式来撑持数据的数字化零碎利用，等内部解决了之后，再来改善外部的数字化零碎。 （2）先解决粗线条的流程对于传统的制作企业，刚刚启动数字化转型时，应该思考粗线条的流程和治理，不要一下子进入到精细化治理。 四、数字化转型门路示例（解决方案） 假如一家传统制作企业站在数字化转型的终点，决定要开始进行数字化转型。这里有一个通用的数字化转型门路，给大家做肯定的参考，不肯定适宜所有企业。 1、管理制度和标准化作业第一步是组织的重构，这是一个长期的过程，企业须要抉择一位适宜的leader来领导数字化转型，适当调整现有的组织构造来配合实现。数字化转型启动后，须要看企业现有的治理思维形式有无妨碍改革的中央，以及标准化作业里有无改革的根底。 2、两化交融阶段管理制度和标准化作业条件满足后，在工业物联网的撑持下可实现工业自动化和信息化交融。这是企业外部的两化交融，能够采集大量的无效数据并给企业提供大数据分析。 3、工业互联网阶段两化交融后再进一步倒退，能够看到一个新模式——工业互联网，这也是工信部在大力推广的一个新平台，很多企业都在提供并凋谢应用。当然，目前市场上的工业互联网平台还处在十分晚期的阶段，只适宜十分高级的利用。如果工业互联网平台成熟了，实践上可能很好地实现产业链的上下游集成，让产业链的上下游建设数据通道。一旦有了比拟好的工业互联网撑持，保护智能化也能够实现并广泛应用。 4、制造业的新模式在工业互联网的根底上，能够衍生出很多制造业转型的新商业模式，比方：制造业服务化。如果原来的产线用来生产产品并销售产品，那么当初能够把产线作为一种服务售卖，客户能够购买产线，工厂为其生产产品。最初，我对数字化转型倡议是：企业不要冀望数字化转型能够一次解决所有问题，应该先瞄准一个问题解决掉，实现业务价值后，再去思考另一个问题。 正当并且无效地使用企业管理系统，不仅能够让咱们工作颠三倒四地进行，还能最大水平保障工作指标的达成。我举荐应用织信informat，它内置了100+的利用模板，笼罩我的项目、营销、人事、企业服务、集体及组织等多个利用场景。领有在线搭建性能，点击一键装置，即可收费应用。成为企业开启数字化转型的重要引擎。

通常来说，中小企业尽管规模不如大型企业，但坏话说的好麻雀虽小确五脏俱全，所以中小企业，很多时候也须要面临：企业外部销售治理、市场拓展、制作生产、财务会计、人事管理等等一系列的问题。所以，中小企业在抉择企业治理软件工具的时候也得精挑细选。 目前市场上，各类企业管理软件层出不穷，品质也是参差不齐。像平时大家都很常见的如：ERP企业资源打算、CRM客户关系治理、OA办公自动化、HR人力资源、员工绩效考核等等。 很多时候，作为中小企业在抉择企业管理软件时，往往一开始思考的是“一步到位”或者是“够用就行”。但其实这两种，均不能很好的满足于企业的需要。为什么这么讲？ 讲个故事，大家就明确了！ 话说，经营多年的企业老板沈世（省事），随着公司的规模壮大，也慢慢意识到了系统化治理企业的重要性，而后就去网上搜“企业管理软件”，而后，也看了很多大平台目迷五色的宣传，但仍然感觉毫无脉络。 前面想着这几年也赚了些钱，就买个贵点的吧。俗话说“贵的总是好的，高大上的总是好的，费那么大精力做什么，轻易买一套大品牌的企业管理软件装上，必定没问题！”于是乎，想“省事”的沈世老板，脑子一热，给本人上了一套“高大上”的ERP。 同为企业家的王远（望的远），发现沈世买了企业管理软件，就对涂总说：“你买的那高大上的软件用途不大的，我是依据本人的需要定了一套，反正咱们企业是够用了，这一套能用10年！”这里，沈世和王远都采取了“一步到位”的做法。 故事终局： 故事的终局是：沈世的企业在理论应用过程中发现零碎十分庞杂，而且很多模块对以后企业的理论状况而言还为时过早但绕不过来，同时员工须要破费大量的工夫加入操作培训，加上治理形式由原来的粗放式变成了精密治理，治理难度陡然减少。于是本应该是晋升效率，降低成本的管理工具却变成了负重沙包。 上面来看看王远，王远的出发点是“实用主义”。所以在软件运行初期的确起到了不小的作用，而企业管理软件也的确帮忙王远的企业顺利成长。但过了五年后，王远慢慢发现目前的企业管理软件性能不够用了，而当初也没有预留接口。无奈之下，只能花钱从新购买一套企业管理软件。 故事总结： 故事讲完了，沈世的行为有肯定的从众心理和凡勃伦效应，即认为贵的就是好的，而且还可能为本人颜面增光但漠视了企业管理软件自身的功能性实用性，这一步迈得太大，过犹不及。 而王远的问题在于他漠视了企业倒退的不确定性，没有预留接口，导致在企业治理软件工具在企业进行改革的时候，因无奈满足以后的需要，导致软件失去效应。 这是一个典型的“一步没到位”的案例。所以，中小企业在抉择企业管理软件的时候肯定不能焦急，还需依据本人的理论须要抉择适宜本人的产品！也要为了企业的久远做思考。 所以，中小企业在抉择管理软件时，要明确这3个要点！ 1、回绝高大上 从下面的故事，咱们能够看出“一步到位”是不事实的，所以，中小企业在筛选企业管理软件时，应该贴合企业理论倒退须要去选。而且，当初很多软件都提供收费试用，大家也能够抽空本人去体验。 2、自在模块 尽管绝大多数企业管理软件也都是模块化构造，但大型企业须要的是稳固的构造，而中小企业更加须要的是灵便的构造。因而，可能自由组合的模块对于企业的疾速倒退可能起到很好的符合作用和推动作用。后期取得成本低，倒退过程中还可能随时调整模块的数量和构造乃至实现二次开发、零碎对接降级等。时刻把控老本和工具的符合度，就像乐高积木一样实现低成本定制化搭建。 3、流程梳理 企业管理软件是不便企业管理者优化工作流程，进步工作效率的信息化零碎。所以在搭建之前，大家要和软件供应商进行深刻沟通，把本人企业的理论状况让软件供应商来进行流程梳理，而后联合具体须要制定方案。所以，中小企业在抉择企业管理软件时，倡议多从灵活性和组合性登程，在老本可控的状况下尽量抉择定制类型软件。 如大家想更深刻的理解企业管理软件，我举荐应用织信，织信是一款高度自定义的低代码开发平台，它可能依据企业需要，低成本高效率地帮忙管理者搭建一站式的企业管理软件（如：OA办公零碎、CRM管理系统、BPM业务流程、HR人事管理、项目管理等零碎搭建），成为企业开启数字化转型的重要引擎。

商业智能通过易于应用的数据管道，数据协同，智能剖析，数据可视化工具和仪表板为业务用户提供能源。这些应用程序使企业更容易实现其企业指标，并进步了业务KPI来治理其资源并与客户进行整体交互。BI市场蓬勃发展，在2019年报告的支出为205亿美元，预计到2025年将达到405亿美元，在2020年至2025年的预测期内复合年增长率为12％。 Analytics Insights会针对不同业务性能的古代企业编译商业智能（BI）用例： 运作形式企业能够部署BI平台，以自动化手动报告流程，报告自动化和其余企业系统集成。这将通过交互式仪表板将客户关系治理（CRM）数据交到销售团队手中，该仪表板提供及时，可操作的信息和显著的竞争劣势。 自助服务BI施行可在业务用户和IT之间建设无效的合作，以最大化利益相关者的专业知识。这使企业和BI分析师专一于宏观策略和长期翻新（例如企业数据治理），而不是人工钻研和报告工作。 钻研与报告Qlik，Tableau和Power BI等BI平台可帮忙投资者关系团队拜访无关投资者所有权，实时钻研，数据预计和会议剖析的重要信息。企业能够利用BI平台来分析和解决钻研和报告矩阵的数据。风行的BI平台可确保企业及其利益相关者的数据合乎令人难以置信的高安全性规范。 财务剖析财务问题对企业具备长久的影响。商业智能平台可让您深刻理解组织在各个层面上的绩效。 这有助于他们注视团队的生产力，最滞销的产品，特定部门发明的支出以及泛滥不同的观点。因而，企业能够立刻关注忽然的财务降落，并能够在问题变成微小的关注之前解决问题。 绩效治理商业智能工具能够轻松地测量和示意大量多样化数据集的运行状况，使企业可能执行“运行状况查看”，以将绩效治理矩阵的每个方面都捕捉到一个繁多的分数中，包含技术有效性，手动绩效，比率 技术效率对手动性能的评估，并实现了客户价值治理。 客户体验旅行和运输公司部署了BI工具，以加重乘客的旅行压力； BI仪表板显示给定部门中实时乘客的交通流量，并使旅行业的员工为交通状况的变动做好筹备。借助Qlik，Tableau和Power BI的采纳，旅行和运输公司可能以更少的致力来连贯各种数据源，并应用这些数据比以往任何时候都更安稳地运行其业务。 工艺效率Qlik，Tableau和Power BI商业智能平台为具备其数据集和KPI的营销，经营和销售部门提供了定制的套件。BI工具可用于简化企业内的流程，例如，如果企业发动了宽泛的广告流动，它能够应用其提供的无限剖析工具不仅能够在Google Ads或Facebook Ads中跟踪其成果，还能够剖析广告流传如何影响业务销售程度的更广大的前景。 营销学商业智能解决方案通过自动化报告流程来节俭营销剖析团队每天的工作工夫。它们还使规模更大的营销团队可能制订其区域性的个性化数字营销流动。 依据对客户行为的综合剖析，企业能够创立独自的广告系列来领导其营销工作。可能查看和跟踪实时数据意味着团队能够对客户的行为做出反馈并优化其营销流动。 这将进步转换率并进步客户保留率。

环境需求最低硬件配置：1核CPU，1G内存（1+1）提示：如果你的应用较多，而主机节点的硬件配置较低，建议在部署节点时开通虚拟虚拟内存；生产环境建议使用2G或以上内存；推荐安装系统：Ubuntu-16.04、Ubuntu-18.04、CentOS7.X、Debian9X的64位的纯净的操作系统；URLOS安装curl -LO www.urlos.com/iu && sh iupsi-erp-企业管理软件安装流程登录URLOS系统后台，在应用市场中搜索“redmine”，找到之后，直接点击安装按钮填写服务名称、选择运行节点、选择智能部署填写域名：www.aaa.com（这里填写自己的域名）创建数据库然后点击“提交”按钮，等待部署完成； 初始化数据库 开放数据库的外网访问端口，填写服务端口3306请手动导入mysql数据，文件位置：/www/PSI/psi.sql安装mysql客户端 apt-get install mysql-client或者 yum install mysql-client或者下载gui客户端 在终端用mysql客户端连接数据库： mysql -h 数据库的地址 -P 3306 -u 数据库用户名 -p'密码'切换数据库： use 数据库名导入sql文件： source sql的文件路径登录账户：admin 密码：admin

工作单元用于维护受业务事务影响的对象列表，并协调变化的写入和并发问题的解决。如下：1）运行机制：关键：是提交时，决定要做什么。它打开一个事务，做所有的并发检查（使用悲观离线锁或乐观离线锁）并向数据库写入所做的修改。（开发人员根本不用显示调用数据库更新方法）记录对象更新的方法：调用者注册方式：用户如果改变了某个对象就必须将他注册到工作单元，任何没有注册的对象提交时都不会写入数据库。　对象注册方式：注册方法置于对象中，从数据库加载对象会将加载的对象注册为“干净”的，setting方法将要设置的对象注册为“脏”的。　工作单元控制器：工作单元控制所有数据库的读操作，一旦对象被读取，将将它注册为“干净”的对象。工作单元在读操作时将产生一个拷贝，在提交时比较当前对象和拷贝对象（这种的办法是指发生改变的对象），看对象是否发生了改变。　用途：数据库（使用引用完整性时保证更新顺序、批量更新）、事务资源（调整消息队列、事务监控）.Net环境工作单元实现：使用无连接的数据集，每一行都有版本（当前版本、原始版本、建议版本）、状态（不变、增加、删除、修改）概念2）使用时机：基本目的：记录操作过的各种对象，以便知道为了使内存中数据与数据库同步需要考虑哪些对象。2. 标识映射通过在映射中保存每个已经加载的对象，确保每个对象只加载一次。当要访问对象时，通过映射来查找它们。　1）运行机制：键选择：数据表主键（或其他简单的数据类型）显示的还是通用的（如findPerson(1)，还是find(“Person”, 1)？）：当所有对象键类型相同时使用通用的，其他情况下使用显示的数量（单映射、多映射）：（没看明白）标识映射存放位置：有工作单元时，放在工作单元；没有工作单元时，捆绑到会话的注册表2）使用时机：一般来说，用一个标识映射来管理所有修改了的数据库读出数据；作为数据库读取操作的告诉缓存。3. 延迟加载一个对象，它虽然不包含所需要的所有数据，但是知道怎么获取这些数据1）运行机制：4种实现方法：延迟初始化：实现思想：每次访问属性域都要先检查该域是否为空。如果为空，在返回域值之前计算出这个域的值（注意这个域需要自封装，即便是类的内部也只能通过它来访问）优缺点：简单，但往往会在对象和数据库间强加依赖关系适用场景：活动记录、表数据库入口、行数据入口虚代理：定义：虚代理是这样一个对象，它看起来应该是域中的一个对象，但实际上它并不包含任何东西。只有当他的一个方法被调用时，它才从数据库加载适当的对象优缺点：看上去完全就是需要的对象，但并不真的是那个对象，容易陷入标识问题；同一个实对象，可能有多个不同对象特征的虚代理（需要覆盖Equals方法，而不用标识方法）适用场景：数据映射器值保持器：实现思想：要想获取某对象，可以访问值保持器得到它的值，但只有第一次访问值保持器时它才真正从数据库读取数据优缺点：可避免标识问题；类需要知道值保持器的存在，丧失强数据类型显式性；重影：实现思想：当从数据库加载对象时，它只包含其ID。当每次要访问某个域时，它就会加载其完全状态（可以把域数据分为不同组，按需加载）延迟加载的问题：继承（虚代理、重影，需要知道要创建什么类型的重影或虚对象）；波动加载（产生超出需要的数据库访问），影响应用程序性能（解决办法：不适用延迟加载集合中的项，但集合整体可以延迟加载）适用场景：面向方面的程序（将延迟加载置于一个单独的方面，能独立改变延迟加载策略）2）使用时机：最佳时机：需要额外的调用，并且当使用主对象时所调用的数据没有到的时候（取决于加载一个对象时需要从数据库读取多少数据和数据库调用的次数）

表数据入口　充当数据库表访问入口的对象，一个实例处理表中所有的行。1）运行机制：　表数据入口包含了用于访问单个表或试图的所有SQL，如选择、插入、更新、删除等。其他代码调用它的方法来实现所有与数据库的交互。　表数据入口可以和表模块一起使用，它产生一个记录集数据结构由表模块处理2）使用时机：　数据入口特别适用于事务脚本，行数据入口和表数据入口间的选择归结于如何处理多数据行，当结果集的表现便于事务脚本处理时，用表数据入口。3）示例：　如下2图分别是普通情况下、充分利用.net特征下的表数据入口实现：　2. 行数据入口　充当数据源中单条记录入口的对象，每行一个实例。1）运行机制：　特征：行数据入口是和单条记录及其相似的对象，如数据库中的一行（该对象中数据库中的每一列变成了一个域）　问题：在哪里存放产生该模式的查找操作？鉴于选择静态查找方法不支持为不同数据源提供不同查找方法的多态，需要设置单独的查找方法对象（这样关系数据库每一张表都一个查找方法类和入口来获得结果）　行数据入口和活动记录之间的区别：是否存在任何领域逻辑，如果存在，则是活动记录2）使用时机：　事务脚本（关于表数据入口和行数据入口之间的选择，参考表数据入口）　行数据入口可以和数据映射器一起配合使用：行数据入口从元数据自动生成，数据映射器由手动实现3）实例：　3. 活动记录　一个对象，它包含数据库表或视图中的某一行，封装数据库访问，并在这些数据上增加了领域逻辑1）运行机制：　活动记录的本质是一个领域模型，这个领域模型中的类和基数据库中记录结构十分吻合。　活动记录通常具有如下方法：　由SQL结果集中的一行构造一个活动记录实例；　为将来对表的插入构造一个新的实例；　用静态查找方法来包装常用的SQL查询和返回活动记录（也可以分离为一个单独的类）；　更新数据库并将活动记录中的数据插入数据库；　获取或设置域；　实现部分业务逻辑。2）使用时机：　适合于创建、读、更新、删除等不太复杂的领域逻辑；　优点：简单，容易创建，易于理解；　缺点：要求对象的设计和数据库的设计紧耦合，项目中难以进一步重构；当业务逻辑复杂，对象间有引用、集合和继承等关心时，难以映射到活动记录3）示例：　其中，标圈的是领域逻辑实现。4. 数据映射器　在保持对象和数据库（以及映射器本身）彼此独立的情况下在二者之间移动数据的一个映射器层，如下：　1）运行机制：　主要功能：分离领域和数据源　延时加载　基于元数据的映射2）使用时机：　业务逻辑复杂，数据库方案和对象模型需要彼此独立演变时3）实例：　其中，DataMapper实现了IPersonFinder接口，用于查找方法实现。

事务脚本1）调用数据库：事务脚本将所有逻辑组成单个过程，在过程中直接调用数据库，或者只通过一个简单的数据库封存器。2）脚本处理：每个事务都有自己的事务脚本，尽管事务间的公共子任务可以被分解成多个子程序。3）运行机制：a.事务脚本应该置于与其他处理表现层和数据源层的类相独立的类中，把事务脚本组织成类的两种方法：a. 将数个事务脚本放在一个类中，每个类围绕一个主题将相关的事务脚本组织在一起；b. 使用Command模式，每一个事务脚本对应一个类 (command)4）使用时机:业务逻辑简单场景（同时注意谨慎提取公共子程序以减少代码冗余），当业务复杂时则需要建立领域模型5）优点：当问题本身是简单的时，使用事务脚本可以加快开发速度，而且运行更快6）示例：假如有如下需求：数据库设计为：其中，RevenueRecognition表引用Contract表的Id作为外键。根据需求和数据库设计，事务脚本类图设计为：这里，Gateway为数据库访问封存器，RecognitionServices为事务脚本类。CalculateRevenueRecognitions方法用于计算并保存需入账信息（合同编号、时间、收费金额），RecognizedRevenue用于按照合同编号、指定日期查询已收费用。应用程序只需要分别单个调取这2个方法即可。2. 领域模型1）运行机制领域模型与数据库模型的区别：领域模型混合数据和处理过程，拥有多值属性和复杂的关联网，并且使用继承、策略、设计模式，是一张由互联的细粒度对象组成的复杂网络；使用领域逻辑的一个常见问题: 领域对象过于臃肿，可能会产生冗余代码数据库映射：简单领域模型可以使用活动记录，而复杂领域模型需要使用数据映射器。领域模型应当使用细粒度的对象，这些对象应有细粒度的接口。2）使用时机当业务规则复杂多变，涉及到校验、计算、衍生时。数据库交互方式：首选数据映射器3）示例：对于上文中需求，设计类图如下：　可以看到，这里收费方式使用了策略模式。3. 表模块表模块以一个类对应数据库中的一个表来组织领域逻辑，而且使用单一的类实例来包含将对数据进行的各种操作程序。表模块与领域逻辑的区别：如果有多个订单，领域模型对每个订单都有一个对象，而表模块则只用一个对象来处理所有订单（表模块没有标识符来标出它所代表的实体对象）。1）运行机制长处：允许你将数据与行为封装在一起，同时有可以充分利用关系数据库的优点2）使用时机当使用记录集存取表数据时使用（表模块很大程度上依赖于以表方式组织的数据）　3）示例：设计类图如下：　4. 服务层服务层定义了应用的边界和从接口客户层角度所能看到的可用操作集。它封装了应用的业务逻辑、事务控制及其操作实现中的响应协调。　1）运行机制业务逻辑分类：领域逻辑、应用逻辑两种基本的实现方法：领域外观方法：服务层以领域模型之上的瘦外观集合方式实现（负责实现外观的类不包含任何业务逻辑，所有业务逻辑均由领域模型实现）操作脚本方法：服务层由一组相对复杂的类组成，这些类直接实现应用逻辑，但将领域逻辑委托给封装好的领域对象类服务层接口时粗粒度的，必要时候可以远程调用（在服务层之上增加远程外观或者直接让服务层实现远程接口）　2）使用时机服务层优点：它定义了一个公共的应用操作集合，这个集合可被各种客户使用，而且服务层在每个操作中都会协调应用的响应。当业务逻辑有多种客户，或者用例响应中的多个事务性资源，则需要服务层

思考三个方面的技术实践：持续集成、驱动测试开发和重构1. 从领域层开始1）事务脚本模式最简单，适合于在关系数据库之上构建；领域模型需要非常专业的技术，还有鱼数据库的连接；表模块模式折中，在.Net这类有非常强大记录集支持的环境非常合适2）理论上，可以根据架构来选取工具；实践中，可以让架构和工具相匹配2. 深入到数据源层1）事务脚本的数据源：可供选择的数据库模式为：行数据入口和表数据入口，两者之间选哪个取决于实现平台的方便以及系统未来的发展方向（如：开发平台所包含的工具，比如支持记录集合工具）2）表模块的数据源：有一个良好的记录集框架 -> 与表数据入口模式配合得天衣无缝3）领域模型的数据源：如果模型相当简单（如只有十几个与数据库相关的类），则活动记录即可；如果希望耦合更松一些，可以用表数据集入口或行数据入口；当更复杂性时，可以考虑使用数据映射器（工作单元模式取作用）3. 表现层1）如果情况允许，尽可能使用html而不是胖客户界面；2）如果走html路线，使用mvc；3）.net使用页面控制器 + 模板视图，Java使用前端控制器 + 模板视图；4）站点面向文档，使用页面控制器，复杂情况下可考虑使用前端控制器；5）视图选择：模板视图（服务器页面）、转换视图（XSLT）4. 一些关于具体技术的建议5. 其他分层方式

分布对象的诱惑：中间件的对象分布对上层透明崔然非常有用，但跨进程、跨机器（还有网络）调用，影响性能！2. 远程接口和本地接口：　1）远程访问的对象需要使用粗粒度接口，而本地访问的对象需要使用细粒度接口（优化性能时，本地接扣可以提供粗粒度对象）　2）基于1），就不能把在单进程中设计的类原封不动地搬到分布模型环境中　3）分布对象设计第一定律：不要分布使用对象！　4）怎样有效利用多处理器资源：使用集群系统（在每个处理器上都部署所有对象，每个处理器上的对象都只需要用到本地调用 -> 运行更快，还可以使用细粒度接口设计对象模型）3. 必须使用分布的情况　1）传统客户机/服务器架构　2）应用软件与数据库　3）web服务器和应用服务器（指的是web service么？ 没搞懂！）　4）不同厂商的软件包4. 关于分布边界　1）远程外观：进程内使用细粒度对象，分布边界上放置粗粒度对象　2）数据传输对象：一般只引用其他数据传输对象和一些如字符串等原始类型对象　3）代理：用延迟加载来传递对象5. 分布接口　1）如果两个系统使用相同的平台构建，使用系统自己的远程调用机制高效得多！（web service虽跨平台，但传输数据来回转换增加不少开销）　2）使用http协议和远程面向对象API（没弄明白怎么玩）　3）异步、基于消息的处理方式

无状态的价值：无状态可以仅用很少的对象就可以处理很多的用户，空闲状态的用户越多，无状态服务器就越有用2. 会话状态：相关性：会话状态只与当前会话有关，它存在于业务事务中，与其他会话及他们的业务事务是分开的；与记录数据信息的区别：记录数据时长期保存在数据库中的持久化数据，它对所有会话可见，会话状态需要提交成为数据库中的记录；最大问题：出现在处理隔离性的时候（同时操作，或者相关联操作）不能把会话中所有数据都看成是会话状态3. 存储会话状态的方法：1）存储会话状态的3种方法：客户会话状态：在客户端保存数据（在web中可用url、cookie、hidden域等）适用场景：会话数据较少、用户经常取消会话（如B2C用户直接关闭站点消失）问题：安全性、完整性服务器会话状态：在服务器内存、文件系统、一张简单的数据库表（以会话标识号为key、以已序列化对象为值）优点：容易直接访问会话状态数据库会话状态：在服务器端存储（将数据分解为多个表和域）优点：状态持久化不易丢失问题：隔离性差（需要将会话数据与记录数据相隔离）以上3种模式并不相互排斥，可以混合使用。使用时，还需要注意：客户机崩溃、服务器死掉、网络连接断掉2）会话扩容：会话迁移：允许一次会话从一台服务器转移到另一台服务器，从而可以有一台服务器处理一个请求，其他服务器处理其他请求优点：可均衡服务器缺点：难以找到会话状态，难以支持会话迁移服务器亲和：某次特定会话的所有请求只能由一台服务器处理 缺点：当客户端有使用代理是，可能会有大量负载集中在某台服务器上

离线并发：多个数据库事务中支持多线程的各种应用服务器1. 并发问题：1）丢失更新（同时编辑文件，相继保存，最终丢失先保存者更新的内容）2）不一致性（读取期间，数据有更新）2. 执行语境：1）从与外界交互角度看的2个语境：请求：对应于软件工作的外部环境发出的单个调用，处理请求的软件会决定是否返回一个应答（过程大部分是在服务器端进行，而客户端则假设为在等待应答）会话：客户端和服务器端之间一次长时间的交互2）操作系统的2个语境：进程：重量级的执行语境，将其正在处理的内部数据域外部隔离开（有效隔离，减少冲突，但需要消耗很多资源）线程：轻量级的执行语境，一个单独的进程里可以存在多个线程（可以充分利用资源，但易导致并发问题）3. 隔离与不变性：企业应用2个解决方案：1）隔离：方案1：划分数据，使得每一个片数据都只能被一个执行单元访问（操作系统为每个进程单独分配一片内存，并且只有这个进程可以对这片内存进行读写操作）方案2：文件锁，一个人打开文件，其他人再无法打开或者只打开该文件只读拷贝并且不能修改（好的并发设计应该是：找到各种创建隔离区的办法，并且保证在每个隔离区里能够完成尽可能多的任务）2）不变性：方案1：识别哪些是不变的数据（只有在共享数据可以修改的情况下，并发问题才会出现），不用考虑这些数据的并发问题二广泛地共享它们方案2：把那些只读取数据的程序分开，让他们只是用拷贝的数据源4. 乐观并发控制盒悲观并发控制：1）2种锁：乐观锁：关于冲突检测的（仅当提交更新时才检查冲突）优点：并发性高，限制较少，使用起来比较自由缺点：业务数据比较复杂，难以自动合并，并且使用者难以发现差别时，只能丢弃原有数据，从头开始更新悲观锁：关于冲突避免的（只要有人已是用当前数据或者文件，拒绝其他人使用当前数据或文件）优点：减少并发程度缺点：用户体验差两种策略选择标准：冲突的频率与严重性（冲突少或者冲突后果不严重时，选择乐观锁；否则选择悲观锁）2）避免不一致性：a. 检测不一致读：悲观策略：通过读加锁（read lock，共享锁）和写加锁（write lock，排他锁），可以一次多个人对同一份数据加只读锁，但只要有人得到一个只读锁，其他人就都无法得到写锁；一旦有人得到一个写锁，其他人都不能得到两种所中任意一种乐观策略：基于数据的某种版本标识（时间戳或者顺序计数器），核对将要更新数据的版本标识和共享数据的版本标识，如果两者一样，系统允许更新数据并更新共享数据的版本标识b. 时序读：每次读取数据时都是用某种时间戳或其他不变的标签作为约束条件，数据库根据时间或者标签返回数据（源代码控软件可以用，但数据库比较困难并且代价昂贵）3）死锁：处理死锁的方法：a. 用软件来检测死锁的发生，选择一个牺牲者，放弃他的工作和他所加的锁；b. 给每个锁都加上时间限制，一旦达到时间限制，所加的锁就会失效，工作就会丢失；防止死锁的方法：强制人们在开始工作时就获得所有可能需要的锁，在此之后就不再允许得到更多的锁；可以硬性规定每个人获得锁的顺序（如按姓名字母顺序）5. 事务：1）ACID：原子性、一致性、隔离性、持久性2）事务资源：定义：可以进行事务处理的任何事物事务控制方法：保证事务尽可能短（尽可能不让事务跨越多个请求，跨越多个请求的事务称为长事务）；尽可能晚打开事务3）减少事务隔离以提高灵活性：SQL的4种隔离级别：可串行化的、可重复读、读已提交、读未提交不必给所有的事务设置相同的隔离级别，而应该仔细观察每个事务并根据每个事务具体情况来决定如何权衡灵活性与正确性4）业务事务和系统事务：系统事务：由关系数据库系统和事务监视器所支持的事务 （一般不用干预）业务事务：简单办法：在单个系统事务中执行完整的业务事务（产生长系统事务）；复杂的，采用离线并发（通过工作单元来保存更新数据）6. 离线并发控制的模式：乐观离线锁、悲观离线锁7. 应用服务器并发：每会话一线程 VS 每会话一进程：线程节省资源，但创建和进入隔离区很重要

构建web服务器上应用程序的2种方法：1）使用脚本：CGI、Java Servlet，通过write stream操作输出字符串；适合于解释请求消息2）使用服务器页面：把程序和返回文本也组合在一起，在html中编写返回页面（Asp、php、jsp等）；适合于格式化应答消息1. 视图模式：1）转换视图：特点：使用程序的一种转换风格（如XSLT)2）模板视图：特点：允许你在网页结构中编写表现层，并允许在网页中嵌入标签，用以知名网页中动态内容需要导向到哪里（如ASP、JSP、PHP等）　优点：提供强大功能、灵活　缺点：代码混乱以至于难以维护3）两步视图:2个阶段：由领域数据产生一个逻辑屏幕，然后把它发送到html网页中。（每一个屏幕都有一个第一阶段的视图，而整个程序中只有一个第二阶段的视图）优点：它可以决定把什么样的html网页用在一个地方，全局改变html变得容易缺点：当站点设计得过分精细时，通常不容易提取出很好的逻辑屏幕结构2. 输入控制器模式：1）输入控制器2个责任：处理http的请求消息；根据请求的消息来决定下一步做什么2）2个模式：为每个页面准备一个输入控制器，输入控制器再创建适当的对象来完成处理，并实例化适当的视图来返回结果；单个对象处理所有请求消息，创建一个分离的对象来处理它（前端控制器）。【当站点行为结构有所改变时，可以避免重新配置web服务器】

关系数据库之所以取得成功，最重要的原因之一就是SQL的存在，它是数据库通信标准语言。1. 架构模式：驱动领域逻辑访问数据的方式：SQL语句嵌入在程序设计语言中；行数据入口、表数据入口：把SQL访问从领域逻辑中分离出来，并把它放到独立的类中（让它们以数据库中的表结构为基础，每一个数据表对应一个类），这些类为数据库建立了一个入口；活动记录：领域模型简单时，每个领域对象负责对应数据库的表的存取过程数据映射器：领域模型复杂时，处理数据库和领域模型之间的所有存取操作，并且允许双方都能独立变化面向对象数据库：领域模型不管有多复杂，均可使用（因为风险，使用不多）。主要好处在于能够提高生产率！2. 行为问题：1）所谓行文问题，就是如何让个中对象从数据库中读取出来以及存到数据库中2）工作单元：充当数据库映射的控制器，会跟踪所有从数据库中读取的对象以及所有以任何形式修改过的对象，并将更新提交到数据库（用来解决内存对象和数据库中数据同步的问题）3）标识映射：在标识映射里记录读取的每一行，防止同一对象重复加载4）延迟加载：减少领域模型每次读取的数据3. 读取数据：1）查找器：读取数据的时候，可以把读取数据的方法看做一个查找器2）查找器对象：如果数据库交互类基于表，把插入和更新操作也绑定在查找器方法中；如果数据库交互基于行的类，创建独立的查找器对象（每个查找器类都有很多封装了SQL语句的方法，当执行查询操作时查找器对象返回一个适当的基于行的对象集合）3）读取数据性能经验法则：如果需要，尽量一次读取多行；需要多个表数据时，使用Join4. 结构映射模式：1）关系的映射：解决关系表间关联关系和对象间引用关系的方法：通过对象中的一个标识域来保持每个对象的关系特性，并且通过查找这些值来保持对象引用和关系键之间的相互映射对于一些小的值对象（比如日期范围和钱），不需要用标识域来把对象间引用变为外键（不应该描述成数据库中它们自己的表），而应去除值对象中所有的域，以嵌入值方式把它们嵌入到关联对象中也可以通过序列化LOB将一组对象存储为表中的单个列2）继承：单表继承：为继承体系层次中的所有类建立一个表（修改容易并且避免join，但每一行都必须为每种可能地子类博阿六一些列，浪费空间）具体表继承：为继承体系层次中每个具体类均建立一个表（避免join操作，允许从一个表中获取一个对象，但改变起来比较困难，如对超类的任何改变都不得不改变所有的表和映射代码）类表继承：为继承体系层次中每个类均建立一个表（需要多个join操作来载入一个对象，通常会损失性能）以上3种模式，需要考虑自己的环境和偏好（Martin倾向于：使用单表继承，用另外2个模式辅助来帮助解决不可避免的不相关和无用列问题）5. 建立映射：自己选择数据库方案：使用经典数据库设计技术围绕数据来设计表，使用行数据入口或者表数据入口把SQL从领域逻辑中剔除使用已存在数据库方案：简单的领域逻辑可创建行数据入口或者表数据入口类来模拟数据库，并在此之上创建领域逻辑。复杂的逐步建立领域模型并包含数据映射器对于多个数据源：建立多个映射层，每个数据源一个。 如果数据非常类似，可把数据从内存方案中转化到逻辑数据存储方案，映射从逻辑数据存储方案到实际物理存储方案（第二部包含区别）6. 使用元数据：元数据映射基于把映射浓缩到元数据文件的方法。元数据文件详细描述数据库中列如何映射到对象的域。如：7. 数据库连接：数据库连接池8. 其他问题：select * from 的问题多使用预编译好的静态SQL

模型抉择：1）领域逻辑复杂度：　2）抉择：　领域逻辑复杂度较低时，选择事物脚本；　如果开发环境拥有大量基于记录集的工具（.Net和VS），可以选择表模块；　开发小组经验丰富时，选择领域模型；　3种模式并不互相排斥，可以同时使用2. 服务层：　1）服务层是从领域层分离出来的，用于置于底层的领域模型或表模块之上　2）服务层用于放置事物控制和安全等功能　3）如果确实需要，服务层尽可能最小化（充当于一个Facade层）

分层优缺点：1）优点：在无需过多了解其他层次的基础上，可以将某一层作为一个有机整体来理解；可以替换某层的具体实现，只要前后提供的服务相同即可；可以将层次间的依赖性减到最低；分层有利于标准化工作；一旦构建好了某一层次，就可以用它为很多上层服务提供支持2）缺点：层次并不能封装所有东西，有时会带来级联修改；过多层次会影响性能；决定建立那些层次以及每一层的职责是什么难以决定2. 企业应用中层次的演化：C/S（领域逻辑放在客户端） -> 领域逻辑放到数据库，作为存储过程 -> 三层架构：表现层 + 领域层 + 数据源层3. 三个基本层次：职责如下：层次职责表现层提供服务，显示信息（例如在Windows或HTML页面中，处理用户请求（鼠标点击、键盘敲击等），HTTP请求，命令行调用，批处理API）领域层逻辑，系统中真正的核心数据源层与数据库，消息系统、事务管理器及其他软件包通信其中，领域层，也称为业务逻辑。它的相关工作：对表现层输入的数据进行验证，根据输入数据或已有数据进行计算，根据从表现层接收到的命令来确定应该调度那些数据源逻辑4. 为各层选择运行环境：1）运行环境：1.数据源层：服务器2.表现层：胖客户，客户端；web：服务器端 （只要可能就用web表现方式，只在必须的情况下才使用胖客户方式）3.领域层：全部运行在服务器端，或者全部运行于客户端，如果必须要分离则至少保证相关的部分在一起2）一旦选择了处理节点，尽可能使所有代码保持在单一进程内完成（可能拷贝在集群中的多个节点上），否则不但损失性能，还会增加复杂性3）复杂性增压器：分布、显示多线程、范型差异（如对象/关系）、多平台开发以及极限性要求

构建计算机系统并非易事。随着系统复杂性的增大，构建相应软件的难度将呈指数增大。同其他行业一样，我们只有在不断的学习中进步，从成功经验中学习，从失败教训中学习，才有望克服这些困难。这本书的内容就是这样一些“学习”经验。只有通过模式的总结和学习，才能更有效地与他人进行交流。—选自《企业应用架构模式》0.1 架构软件业的人乐于做这样的事——找一些词汇，并把它们引申到大量微妙而又互相矛盾的含义。一个最大的受害者就是“架构”（architecture）这个词。我个人对“架构”的感觉是，它是一个让人印象深刻的词，主要用来表示一些非常重要的东西。当然，我也会小心，不让这些对“系统结构”的“不恭之词”，影响到读者对本书的兴趣。很多人都试图给“架构”下定义，而这些定义本身却很难统一。能够统一的内容有两点：一点是“最高层次的系统分解”；另一点是“系统中不易改变的决定”。越来越多的人发现：表述一个系统架构的方法不只一种；一个系统中也可能有很多种不同的架构，而且，对于什么在架构上意义重大的看法也会随着系统的生命周期变化。Ralph Johnson经常在邮件列表上发帖，并提出一些令人关注的见解。就在我完成本书初稿的同时，他又发表了一些关于“架构”的观点。他认为，架构是一种主观上的东西，是专家级项目开发人员对系统设计的一些可共享的理解。一般地，这种可共享的理解表现为系统中主要的组成部分以及这些组成间的交互关系。它还包括一些决定，开发者们希望这些决定能及早做出，因为在开发者看来它们是难以改变的。架构的主观性也来源于此——如果你发现某些决定并不像你想象的那么难以改变，那么它就不再与架构相关。到了最后，架构自然就浓缩成一些重要的东西，不论这些东西是什么。在本书中，我提出一些自己的理解，涉及企业应用主要组成部分和我希望能尽早做出的决定。在这些架构模式中，我最欣赏的就是“层次”，将在第1章中进行详细介绍。全书实际上就是关于如何将企业应用组织成不同的层次，以及这些层次之间如何协同工作。大多数重要的企业应用都是按照某种形式的层次分层设计的；当然，在某些情况下，别的设计方式（如管道方式、过滤器方式等）也有它们自己的价值。在本书中我们将不会讨论这些方式，而把注意力集中在层次方式上，因为它是应用最广的设计方式。本书中的一些模式毫无疑问是关于架构的，它们表示了企业应用各主要组成部分间的重要决定；另外一些模式是关于设计的，有助于架构的实现。我没有刻意区分这两类模式，因为正如我们前面讨论的，是否与架构相关往往带有主观性。0.2 企业应用编写计算机软件的人很多，我们通常把这些活动都称为软件开发。但是软件的种类是不同的，每种软件都有自身的挑战性和复杂性。我是在与几个从事电信软件开发的朋友交谈后，意识到这个问题的。企业应用在某些方面要比电信软件简单得多——多线程问题没有那么困难，无需关注硬件设备与软件的集成。但是，在某些方面，企业应用又比电信软件复杂得多——企业应用一般都涉及到大量复杂数据，而且必须处理很多“不合逻辑”的业务规则。虽然有些模式是适合所有软件的，但是大多数模式都还只适合某些特定的领域和分支。我的工作主要是关于企业应用的，因此，这里所谈及的模式也都是关于企业应用的。（企业应用还有一些其他的说法，如“信息系统”或更早期的“数据处理”。）那么，这里的“企业应用”具体指的是什么呢？我无法给出一个精确的定义，但是我可以罗列一些个人的理解。先举几个例子。企业应用包括工资单、患者记录、发货跟踪、成本分析、信誉评估、保险、供应链、记账、客户服务以及外币交易等。企业应用不包括车辆加油、文字处理、电梯控制、化工厂控制器、电话交换机、操作系统、编译器以及电子游戏等。企业应用一般都涉及到持久化数据。数据必须持久化是因为程序的多次运行都需要用到它们——实际上，有些数据需要持久化若干年。在此期间，操作这些数据的程序往往会有很多变化。这些数据的生命周期往往比最初生成它们的那些硬件、操作系统和编译器还要长。在此期间，数据本身的结构一般也会被扩展，使得它在不影响已有信息的基础上，还能表示更多新信息。即使是有根本性的变化发生，或公司安装了一套全新的软件，这些数据也必须被“迁移”到这些全新的应用上。企业应用一般都涉及到大量数据——一个中等规模的系统往往都包含1GB以上的数据，这些数据是以百万条记录的方式存在的。巨大的数据量导致数据的管理成为系统的主要工作。早期的系统使用的是索引文件系统，如IBM的VSAM和ISAM。现代的系统往往采用数据库，绝大多数是关系型数据库。数据库的设计和演化已使其本身成为新的技术领域。企业应用一般还涉及到很多人同时访问数据。对于很多系统来说，人数可能在100人以下，但是对于一些基于Web的系统，人数会呈指数级增长。要确保这些人都能够正确地访问数据，就一定会存在这样或那样的问题。即使人数没有那么多，要确保两个人在同时操作同一数据项时不出现错误，也是存在问题的。事务管理工具可以处理这个问题，但是它通常无法做到对应用开发者透明。企业应用还涉及到大量操作数据的用户界面屏幕。有几百个用户界面是不足为奇的。用户使用频率的差异很大，他们也经常没什么技术背景。因此，为了不同的使用目的，数据需要很多种表现形式。系统一般都有很多批处理过程，当专注于强调用户交互的用例时，这些批处理过程很容易被忽视。企业应用很少独立存在，通常需要与散布在企业周围的其他企业应用集成。这些各式各样的系统是在不同时期，采用不同技术构建的，甚至连协作机制都不同：COBOL数据文件、CORBA系统或是消息系统。企业经常希望能用一种统一的通信技术来集成所有系统。当然，每次这样的集成工作几乎都很难真正实现，所有留下来的就是一个个风格各异的集成环境。当商业用户需要同其业务伙伴进行应用集成时，情况就更糟糕。即使是某个企业统一了集成技术，它们也还是会遇到业务过程中的差异以及数据中概念的不一致性。一个部分可能认为客户是当前签有协议的人；而另外一个部门可能还要将那些以前有合同，但现在已经没有了的人计算在内。再有，一个部门可能只关心产品销售而不关心服务销售。粗看起来，这些问题似乎容易解决，但是，一旦几百个记录中的每个字段都有可能存在着细微差别，问题的规模就会形成不小的挑战——就算唯一知道这些字段之间差别的员工还在公司任职（当然，也许他在你察觉到之前就早已辞职不干了）。这样，数据就必须被不停地读取、合并、然后写成各种不同语法和语义的格式。再接下来的问题是由“业务逻辑”带来的。我认为“业务逻辑”这个词很滑稽，因为很难找出什么东西比“业务逻辑”更加没有逻辑。当我们构建一个操作系统时，总是尽可能地使得系统中的各种事物符合逻辑。而业务逻辑生来就是那样的，没有相当的行政努力，不要想改变它，当然，它们都有自己的理由。你必须面对很多奇怪的条件。而且这些条件相互作用的方式也非常怪异。比如，某个销售人员为了签下其客户几百万美元的一张单，可能会在商务谈判中与对方达成协议，将该项目的年度到账时间推迟两天，因为这样才能与该客户的账务周期相吻合。成千上万的这类“一次特殊情况”最终导致了复杂的业务“无逻辑”，使得商业软件开发那么困难。在这种情况下，必须尽量将这些业务逻辑组织成有效的方式，因为我们可以确定的是，这些“逻辑”一定会随着时间不断变化。对于一些人来说，“企业应用”这个词指的是大型系统。但是 需要注意的是，并不是所有的企业应用都是大型的，尽管它们可能都为企业提供巨大的价值。很多人认为，由于小型系统的规模不大，可以不用太注意它们，而且在某种程度上，这种观点能够带来一定的成本节约。如果一个小型系统失败了，相对于大型系统的失败，这种失败就不会显得那么起眼了。但是，我认为这种思想没有对小型项目的累积作用给予足够的重视。试想，如果在小型项目上能够进行某些改善措施，那么一旦这些改善措施被成功运用于大型项目，它带来的效果就会非常大。实际上，最好是通过简化架构和过程，将一个大型项目简化成小型项目。0.3 企业应用的种类在我们讨论如何设计企业应用以及使用哪些模式之前，明确这样一个观点是非常重要的，即企业应用是多种多样的，不同的问题将导致不同的处理方法。如果有人说“总是这样做” 的时候，就应该敲响警钟了。我认为，设计中最具挑战性（也是我最感兴趣）的地方就是了解有哪些候选的设计方法以及各种不同设计方法之间的优劣比较。进行选择的控件很大，但我在这里只选三个方面。考虑一个B2C（Business to Customer）的网上零售商：人们通过浏览器浏览，通过购物车购买商品。通过购物车购买商品。这样一个系统必须能够应付大量的客户，因此，其解决方案不但要考虑到资源利用的有效性，还要考虑到系统的可伸缩性，以便在用户规模增大时能够通过增加硬件的办法加以解决。该系统的业务逻辑可以非常简单：获取订单，进行简单的价格计算和发货计算，给出发货信息。我们希望任何人都能够访问该系统，因此用户界面可以选用通用的Web表现方式，以支持各种不同的浏览器。数据源包括用来存放订单的数据库，还可能包括某种与库存系统的通信交流，以便获得商品的可用性信息和发货信息。再考虑一个租约合同自动处理系统。在某些方面，这样的系统比起前面介绍的B2C系统要简单，因为它的用户数很少（在特定时间内不会超过100个），但是它的业务逻辑却比较复杂。计算每个租约的月供，处理如提早解约和延迟付款这样的事件，签订合同时验证各种数据，这些都是非常复杂的任务，因为租约领域的许多竞争都是以过去的交易为基础稍加变化而出现的。正是因为规则的随意性很大，才使得像这样一个复杂领域具有挑战性。这样的系统在用户界面（UI）上也很复杂。这就要求HTML界面要能提供更丰富的功能和更复杂的屏幕，而这些要求往往是HTML界面目前无法达到的，需要更常规的胖客户界面。用户交互的复杂性还会带来事务行为的复杂性：签订租约可能要耗时12个小时，这期间用户要处于一个逻辑事务中。一个复杂的数据库设计方案中可能也会涉及到200多个表以及一些有关资产评估和计价的软件包。第三个例子是一家小型公司使用的简单的“开支跟踪系统”。这个系统的用户很少，功能简单，通过HTML表现方式可以很容易实现，涉及的数据源表项也不多。尽管如此，开发这样的系统也不是没有挑战。一方面你必须快速地开发出它，另一方面你又必须为它以后可能的发展考虑；也许以后会为它增加赔偿校验的功能，也许它会被集成到工资系统中，也许还要增加关于税务的功能，也许要为公司的CFO生成汇总报表，也许会被集成到一个航空订票Web Service中，等等。如果在这个系统的开发中，也试图使用前面两个例子中的一些架构，可能会影响开发进度。如果一个系统会带来业务效益（如所有的企业应用应该的那样），则系统进度延误同样也是开销。如果现在不做决策又有可能影响系统未来的发展。但是，如果现在就考虑了这些灵活性但是考虑不得当，额外的复杂性又可能会影响到系统的发展，进一步延误系统部署，减少系统的效益。虽然这类系统很小，但是一个企业中往往有很多这样的系统，这些系统的架构不良性累积起来，后果将会非常可怕。这三个企业应用的例子都有难点，而且难点各不相同。当然，也不可能有一个适合于三者的通用架构。选择架构时，必须很清楚地了解面临的问题，在理解的基础上再来选择合适的设计。本书中也没有一个通用的解决方案。实际上，很多模式仅仅是一些可选方案罢了。即使你选择了某种模式，也需要进一步根据面临的问题来修改模式。在构建企业应用时，你不思考是不行的。所有书本知识只是给你提供信息，作为你做决定的基础。模式是这样，工具也同样如此。在系统开发时应该选取尽可能少的工具，同时也要注意，不同的工具擅长处理的方面也不同，切记不要用错了工具，否则只会事倍功半。0.4 关于性能的考虑很多架构的设计决策和性能有关。对于大多数与性能相关的问题，我的办法是首先建立系统，调试运行，然后通过基于测量的严格的优化过程来提高性能。但是，有一些架构上的决策对性能的影响，可能是后期优化难以弥补的。而且即使这种影响可以在后期很容易地弥补，参与这个项目的人们任然会从一开始就担心这些决策。在这样的一本书中讨论性能通常很困难。这是因为“眼见为实”：所有那些关于性能的条条框框，不在你的具体系统中配置运行一下，是很难有说服力的。我也经常看到一些设计方案因为性能方面的考虑而被接受或拒绝，但是一旦有人在真实的设置环境中做一些测量，就会证明这些考虑是错误的。本书将提出一些这方面的建议，包括尽量减少远程调用（它在很长时间内都被认为是优化性能的好建议）。尽管如此，还是建议读者在运用这些原则之前，在你的应用中具体试一试。同样，本书中的样例代码也有一些地方为了提高可读性而牺牲了效率。在你的系统中，需要自行决定是否进行优化。在做性能优化后，一定要与优化前进行测量对比，以确定真的得到了优化，否则，你可能只是破坏了代码的可读性。还有一个很重要的推论：配置上的重大变化会使得某些性能优化失效。因此，在升级虚拟机、硬件、数据库或其他东西到新的版本时，必须重新确认性能优化工作的有效性。很多情况下，配置变更都会对性能优化有影响，有时候你真的会发现，以前为了提升性能做的优化，在新环境下居然影响性能。关于性能的另一个问题是很多术语的使用不一致。最明显的例子就是“可伸缩性”（scalability），它可能有6-7种含义。下面我使用其中一些术语。响应时间是系统完成一次外部请求处理所需要的时间。这些外部请求可能是用户交互行为，例如按下一个按钮，或是服务器API调用。响应性不同于请求处理，它是系统响应请求的速度有多快。这个指标在许多系统里非常重要，因为对于一些系统而言，如果其响应性太慢，用户将难以忍受——尽管其响应时间可能不慢。如果在请求处理期间，系统一直处于等待状态，则系统的响应性和响应时间是相同的。然而，如果能够在处理真正完成之前就给用户一些信息表明系统已经接到请求，则响应性就会好一些。例如，在文件拷贝过程中，为用户提供一个“进度条”，将会提高用户界面的响应性，但并不会提高响应时间。等待时间是获得系统任何形式响应的最小时间，即使应该做的工作并不存在。通常它是远程系统中的大问题。假设我们让程序什么都不做，只是调用返回即可，则如果在本机上运行程序，一般都会立即得到响应。但是，如果在远程计算机上运行程序，情况就不一样，往往需要数秒的时间才能得到响应。因为从发出请求到得到响应的数秒时间主要用于排除使信息在线路上传输的困难。作为应用开发者，我经常对等待时间无能为力。这也是为什么要尽量避免远程调用的原因。吞吐率是给定时间内能够处理多大的请求量。如果考察的是文件拷贝，则吞吐率可以用每秒字节量来表示。对于企业应用来说，吞吐率通常用每秒事务数（tps）来度量。这种方法的一个问题是指标依赖于事务的复杂程度。对于特定系统的测试，应该选取普通的事务集合。在这里，性能或指吞吐率，或者指响应时间，由用户自己决定。当通过某种优化技术后，使得系统的吞吐率提高了，但是响应时间下降了，这时就不好说系统的性能提高了，最好用更准确的术语表示。从用户角度而言，响应性往往比响应时间更重要，因此，为了提高响应性而损失一些响应时间或者吞吐率是值得的。负载是关于系统当前负荷的表述，也许可以用当前有多少用户与系统相连来表示。负载有时也作为其他指标（如响应时间）的背景。因此，我们可以说：在10个用户的情况下，请求响应时间是0.5秒，在20个用户的情况下，请求响应时间是2秒。负载敏感度是指响应时间随负载变化的程度。假设：系统A在1020个用户的情况下，请求响应时间都是0.5秒；系统B在10个用户的情况下，请求响应时间是0.2秒，在20个用户的情况下，请求响应时间上升到2秒。此时，系统A的负载敏感度比系统B低；我们还可以使用术语衰减（degradation），称系统B衰减得比系统A快。效率是性能除以资源。如果一个双CPU系统的性能是30tps，另一个系统有4个同样的CPU，性能是40tps，则前者效率高于后者。系统的容量是指最大有效负载或吞吐率的指标。它可以是一个绝对最大值或性能衰减至低于一个可接受的阈值之前的临界点。可伸缩性度量的是向系统中增加资源（通常是硬件）对系统性能的影响。一个可伸缩性的系统允许在增加了硬件后，能够有性能上的合理提高。例如，为了使吞吐率提高一倍，要增加多少服务器等。垂直可伸缩性或称垂直延展，通常指提高单个服务器的性能，例如增加内存。水平可伸缩性或称水平延展，通常指增加服务器的数目。问题是，设计决策对所有性能指标的作用并不相同。比如，某个服务器上运行着两个软件系统：Swordfish的容量是20tps，而Camel的容量是40tps。哪一个的性能更高？哪一个的可伸缩性好？仅凭这些数据，我们无法回答关于可伸缩性的问题，我们只能说Camel系统在单片机上的效率更高。假设又增加了一台服务器后，我们发现：Swordfish的容量是35tps，Camel的容量是50tps。尽管Camel的容量仍然大于Swordfish，但是后者在可伸缩性上却显得比前者更好。假设我们继续增加服务器数目后发现：Swordfish每增加一台服务器提高15tps，Camel每增加一台服务器提高10tps。在获得了这些数据后，我们才可以说，Swordfish的水平可伸缩性比Camel好，尽管Camel在5个服务器以下会有更好的效率。当构建企业应用系统时，关注硬件的可伸缩性往往比关注容量或效率更重要。如果需要，可伸缩性可以给予你获得更好性能的选择，可伸缩性也可以更容易实现。有时，设计人员费了九牛二虎之力才提高了少许容量，其开销还不如多买一些硬件。换句话说，假设Camel的费用比Swordfish高，高出的部分正好可以买几台服务器，那么选择Swordfish可能更合算，尽管你目前只需要40tps。现在人们经常抱怨软件对硬件的依赖性越来越大，有时为了运行某些软件就不得不对硬件进行升级，就像我一样，为了用最新版本的Word，就必须不断地升级笔记本电脑。但是总的来说，购买新硬件还是比修改旧软件来得便宜。同样，增加更多的服务器也比增加更多的程序员来得便宜——只要你的系统有足够的可伸缩性。0.5 模式模式的概念早就有了。我在这里不想把这段历史重新演绎一遍。只是想简单谈谈我对模式和它们为什么是描述设计的重要手段的一些看法。模式没有统一的定义。可能最好的起点是Christopher Alexander给出的定义（这也是许多模式狂热者的灵感来源）：“每一个模式描述了一个在我们周围不断重复发生的问题以及该问题解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动”[Alexander et al.]。尽管Alexander是建筑家，他谈论的是建筑模式，但其定义也能很好地适用于软件业。模式的核心就是特定的解决方案，它有效而且有足够的通用性，能解决重复出现的问题，模式的另一种视角是把它看成一组建议，而创造模式的艺术则是将很多建议分解开来，形成相互独立的组，在此基础上可以相对独立地讨论它们。模式的关键点是它们源于实践。必须观察人们的工作过程，发现其中好的设计，并找出“这些解决方案的核心”。这并不是一个简单的过程，但是一旦发现了某个模式，他将是非常有价值的。对于我来说，价值之一是能够撰写这样一本参考书。你不必通读本书的全部内容，也不必通读所有有关于模式的书。你只需要了解到这些模式都是干什么的，它们解决什么问题，它们是如何解决问题的，就足够了。这样，一旦碰到类似问题，就可以从书中找出相应的模式。那时，再深入了解相应的模式也不迟。一旦需要使用模式，就必须知道如何将它运用于当前的问题。使用模式的关键之一是不能盲目使用，这也是模式工具为什么都那么惨的原因。我认为模式是一种“半生不熟品”，为了用好它，还必须在自己的项目中把剩下的那一半“火候”补上。我本人每次在使用模式时，都会东改一点西改一点。因此你会多次看到同一解决方案，但没有一次是完全相同的。每个模式相对独立，但又不彼此孤立。有时候它们相互影响，如影随形。例如，如果在设计中使用了领域模型，那么经常还会用到类表继承。模式的边界本来也是模糊的，我在本书中也尽量让它们各自独立。如果有人说“使用工作单元”，你就可以直接去看工作单元这个模式如何使用，而不必阅读全书。如果你是一个有经验的企业应用设计师，也许会对大多数模式都很熟悉。希望本书不会给你带来太大的失望。（实际上我在前言里面已经提醒过了。）模式不是什么新鲜概念。因此，撰写模式书籍的作者们也不会声称我们“发明”了某某模式，而是说我们“发现”了某某模式。我们的职责是记录通用的解决方案，找出其核心，并把最终的模式记录下来。对于一个高级设计师，模式的价值并不在于它给予你一些新东西，而在于它能帮助你更好地交流。如果你和你的同事都明白什么是远程外观，你就可以这样非常简洁地交流大量信息：“这个类是一个远程外观模式。”也可以对新人说：“用数据传输对象模式来解决这个问题。”他们就可以查找本书来搞清楚如何做。模式为设计提供了一套词汇，这也是为什么模式的名字这么重要的原因。本书的大多数模式是用来解决企业应用的，基本模式一章（见第18章）则更通用一些。我把它们包含进来的原因是：在前面的讨论中，我引用了这些通用的模式。0.5.1 模式的结构每个作者都必须选择表达模式的形式。一些人采用的表达基于模式的一些经典教材如[Alexander et al.]、[Gang of Four]或[POSA]。另一些人用他们自己的方式。我在这个问题上也斟酌了很久。一方面我不想象GOF一样太精炼，另一方面我还要引用他们的东西。这就形成了本书的模式结构。第一部分是模式的名字。模式名非常重要，因为模式的目的之一就是为设计者们交流提供一组词汇。因此，如果我告诉你Web服务器是用前端控制器和转换试图构建的，而你又了解这些模式，那么你对我的Web服务器的架构就会非常清楚了。接下来的两部分是相关的：意图和概要。意图用一两句话总结模式；概要是模式的一种可视化表示，通常是（但不总是）一个UML图。这主要是想给模式一个简单的概况，以帮助记忆。如果你对模式已经“心知肚明”，只是不知道它的名字，那么模式的意图和概要这两部分就能为你提供足够的信息。接下来的部分描述了模式的动机。这可能不是该模式所能解决的唯一问题，但却是我认为最具代表性的问题。“运行机制”部分描述了解决方案。在这一部分，我会讨论一些实现问题以及我遇到的变化情况。我会尽可能独立于平台来讨论——也有一个部分是针对平台来讨论的，如果不感兴趣可以跳过这部分。为了便于解释，我用了一些UML图来辅助说明。“使用动机”部分描述了模式何时被使用。这部分讨论是使我选择该模式而不是其他模式的权衡考虑。本书中很多模式都可以相互替代，例如页面控制器和前端控制器可以相互替代。很少有什么模式是非它不可的。因此，每当我选择了一种模式之后，我总是问自己“你什么时候不用它？”这个问题也经常驱使我选择其他方案。“进一步阅读”部分给出了与该模式相关的其他读物。它并不完善。我只选择我认为有助于理解模式的参考文献，所以我去掉了对本书内容没有价值的任何讨论，当然其中也可能会遗漏一些我不知道的模式。我也没有提到一些我认为可能读者无法找到的参考文献，再就是一些不太稳定的Web链接。我喜欢为模式增加一个或几个例子。每个例子都非常简单，它们是用Java语言或C#语言编写的。我之所以选择两种语言，是因为它们可能是目前绝大多数专业程序员都能读懂的语言。必须注意，例子本身不是模式。当你使用模式时，不要想当然地认为它会和例子一样，也不要把例子看成某种形式的宏替换。我把例子编得尽量简单以突出其中模式相关的部分。当然，省略的部分并不是不重要，只是它们一般都特定于具体环境，这也是为什么模式在使用时一般都必须做适当调整的原因。为了尽量使例子简单但是又能够突出核心意思，我主要选择那些简单而又明确的例子，而不是那些来自于系统中的复杂例子。当然，在简单和过分之间掌握平衡是不容易的，但是我们必须记住：过分强调具体应用环境反而会增加模式的复杂性，使得模式的核心内容不易理解。这就是为什么我在选择例子时选取的是一些相互独立的例子而不是相互关联的例子的原因。独立的例子有助于对模式的理解。但是在如何将这些模式联合在一起使用上却支持不多。相互关联的例子则相反，它体现了模式间是如何相互作用的，但是对其中每个模式的理解却依赖于对其他所有模式的理解。理论上，是可以构造出既相互关联又相互独立的例子，但这是一项非常艰巨的工作——至少对于我来说是这样。因此，我选择了相互独立的例子。例子中的代码本身也主要用来增强对思想的理解。因此，在其他一些方面考虑可能不够——特别是错误处理，在这方面，我没有花费很多笔墨，因为到目前为止，我还没有得出错误处理方面的模式。在此，那些代码纯粹用来说明模式，而并不是用来显示如何对任何特定的业务问题进行建模。正是由于这些原因，我没有把这些代码放到我的网站上供大家下载。为了让那些基本的思想在应用设置下有所意义，本书的每个样例代码都充满着太多的“脚手架”来简化它们。并不是每个模式中都包含上面所述的各个部分。如果我不能想出很好的例子或动机等内容，我就会把相应部分省略。0.5.2 模式的局限性正如我在前言中所述，对于企业应用开发而言，本书介绍的模式并不全面。我对本书的要求，不在于它是否全面，而在于它是否有用。模式这个领域太大了，单凭一个人的头脑是无法做到面面俱到的，更不用说是一本书了。本书中所列的模式都是我在具体领域中遇到的，但这并不表明我已经理解了每一个模式以及它们之间的关系。本书的内容只是反映了我在写书时的理解，在编写本书的过程中，我对相关内容的理解也不断发展和加深，当然，在本书发表之后，我仍然希望本人对模式的理解还能够继续发展。对于软件开发而言，有一点是可以肯定的，那是软件开发永远不会停止。当你使用模式时请记住：它们只是开始，而不是结束。任何作者去囊括项目开发中的所有变化和技术是不可能的。我编写本书的目的也只是作为一个开始，希望它能够把我自己的和我所了解的经验和教训传递给读者，你们可以在此基础上继续努力。请大家记住：所有模式都是不完备的，你们都有责任在自己的系统中完善它们，你们也会在这个过程中得到乐趣。——选自：《企业应用架构模式》 [Patterns of Enterprise Application Architecture] [英] 福勒 著；王怀民，周斌 译

“我的故事都是和团队技术相关的，自己还真没有什么引人入胜的故事。”当马劲被问到能不能多分享些个人经历故事时他笑着说，我们就干脆怀着好奇聊了聊他和阿里云专有云一路走来的故事。马劲，花名隆猫，阿里云专有云事业部兼企业应用事业部总经理。全面负责专有云团队产品的技术研发、销售、运营管理服务以及产品市场营销等工作，并领导企业应用团队进行云产品的创新孵化，致力于为企业级客户提供优质、可靠、可控的云平台和云服务。在客户需求标准日益提高的环境下，实现多领域的快速增长。终极三问和专有云三定律“阿里云专有云究竟是什么？专有云生命周期管理是否在坚持技术导向？专有云产品现在遵循着什么管理流程？”这三个问题是马劲从2014年领导阿里云专有云团队开始一直到现在不断在问自己的，好在从开始到现在，马劲和他的团队对于这三个问题的答案方向一直没变过，那就是：“阿里云专有云是阿里云的一种部署模式，是标准产品，不是项目定制开发。专有云的生命周期管理必须通过技术能力来满足客户业务和管理需要，要允许客户有权决定是否升级何时升级，但是不能无限制支持多分支版本，必须坚持热升级。专有云产品和架构管理流程由阿里云统一管理，不是法外之地。”马劲严肃的说这是必须遵循的“专有云三定律”，但同时他笑称：“这三个结论其实简单而清晰，这不是神的定义，而是人的选择，是我们的取舍。不过阿里巴巴要拥抱变化，阿里云更要拥抱变化，虽然专有云到现在才四岁，但客户并没有当我们是孩子。客户是期待拥有阿里巴巴的国内互联网公司的能力去帮助他们带来业务创新的，但在使用我们的产品时，又是用类似看待IBM产品的挑剔目光在衡量我们的，所以从一开始我们提供给客户的就应该是高标准的基础设施。”做好专有云是理想不是梦想在加入阿里云之前，马劲已经在IBM就职超过10年，在软件方案设计、开发、实施、技术服务、产品市场等方面有丰富的经验，对于云计算产品技术发展有深刻的理解和洞察。按照常规剧本他似乎并不“应该”出现在阿里云的故事脚本中，但偏偏阿里云迎来了他，他迎来了专有云的一路盛开。“云计算的概念刚在国内IT圈开始被关注时，我就对它特别有好感，你看，云，多浪漫的一个词！” 马劲说道，这句话听着他更像是个富有浪漫主义情怀的人，“不像”个IT人，但当他跟我们说到在做专有云过程中的坚守和抉择时，笔者看出他既有着一个理想主义者的追求也有一个务实主义者的理性。在聊到专有云初始阶段时，马劲提到那时有两大集中讨论点：公共云有各种各样的优势为什么要做专有云，还要做政府和大企业？大家眼中的阿里巴巴服务于中小企业，难道中小企业市场不够吗？实际上，对于政府和大企业，专有化部署、自主可控的运维和运营是唯一选项，是刚需，不满足这一条就没市场，所以专有云要做。阿里巴巴的愿景是让天下没有难做的生意，而专有云是实现普惠科技路上针对政府和大企业的重要一环，是对整个经济体数字化转型的推动，是战略要地。在马劲看来，专有云4年走来的不错成绩是坚持正确的战略决策和果断的执行力打配合的结果。选择我相信的，相信我选择的专有云是站在公共云这个巨人的肩膀上的，有得天独厚的优势，但马劲深知专有云要做好必须打造技术壁垒，持续进行趋势性创新并达成规模化交付，可着其中的挑战和艰辛不可避免也难以言喻。多数金融、政府客户基于对安全问题的考虑需要自主运维，因此交付给客户独立自主运维成为一个必选项。这时的马劲遇到了第一个挑战：如何既能满足规模化交付还能否让客户自主运维？众所周知，阿里云公共云就像罗马城，不是一天建成的，各个产品的部署运维管理各自奔跑，需要上百的PE和大量开发人员进行运维DevOps，而只有做到两三个工作人员即可运维整朵云，才有可能规模化交付。随之而来的另一个大问题就是运维基础设施怎么选？马劲说：“我们相信公共云的先天优势，所以坚定的相信了天基团队。自从2014年底选择了天基，我们一直没有动摇过，选择我相信的，相信我选择的。”这个选择使得公共云和专有云拥有了统一的运维基础设施，马劲和他的团队坚信天基团队在2年时间内能做到全自动1天部署，傻瓜式运维，统一的面向企业组织的运维管理和权限管理。但选择虽然做了，业务并不能等天基两年，需要选一条路径，解决眼前的问题。路径，就是优先级，而这往往决定是否能成功的关键。马劲排优先级的思路就是先解决最短的短板，再解决第二短的短板，选择了“步枪”即先解决当前问题以及与天基团队并肩作战这两种路径双管齐下。按马劲的话说当时是按照紧急程度来排序而不是按照重要性来排序，先通过短平快的方式来解决，只要有当时能彻底解决的解决方案，就用！同时与天基团队一起打拼，两条腿走路。终于，在2017年初，天基团队憋出一个大招，提供了一个近乎完美的框架，专有云企业版V3版本正式发布，选择了天基是专有云能走到今天最对的选择之一，天基团队功不可没。“很多人都喜欢说自己是创业者，但我经常说专有云团队不是创业者团队，我们更关注不同视角，我们是在建设基础设施，并且是坚持建更好的基础设施，就像电站、水坝。但基础设施必须从一开始就具备完备的设计，要负责任，只能成功不能失败，同时还能不断的做的更好。”马劲这么评价自己和团队做的事。后记：“以终为始，看看终局。”在访谈结尾，马劲淡然的说。的确，只有清楚的知道终点在何处并且以初心驱动的人才能真正抵达终点。笔者刚了解到专有云办公区的墙上有这么一段文化宣言：以匠心对真心，以恒心待决心，以创新承初心–专有云，你我同心。通往理想的道路上不乏荆棘，我想正是这句话里的精神领着马劲和他的团队创造出今天的成绩，而这句话我相信也将在未来助他们一步步走的更远更稳。阿里云总监系列课重磅上线！聚焦人工智能、弹性计算、数据库等热门领域，首次集齐12位阿里云技术高管，耗时半年精心打磨，从理论到实践倾囊相授，从零开始绘制技术大牛成长路径，限时直播课程免费报名中！欢迎戳“ https://yq.aliyun.com/promotion/689&tlog=out_aiticai_zongjianke_181206 ”免费报名学习。本文作者：云攻略小攻阅读原文本文为云栖社区原创内容，未经允许不得转载。