1、附錄A外文翻譯一原文局部Challenges of production microservicesAUTHOR ： Benjamin Gotz; Daniel Schel; Dennis Bauer; Christian Henkel; Peter Einberger; Thomas Bauemhansl;JOURNAL:Procedia CIRPSOURCE:ElsevieijournalYEAR:2018PAGES:167-172PUBLISHER:Elsevier B.V.AbstractCurrent production systems use monolithic softwar

2、e solutions. This causes a lack of flexibility, scalability and prevents direct communication between network nodes which is fundamental to face challenges of highly personalized mass production. In order to overcome these drawbacks, the introduction of a service-oriented architecture (SOA) more spe

3、cifically microservices in production are a promising approach. SOA enables developers to distribute applications in a number of small services which communicate via an integration layer e.g. an enterprise service bus. This paper proposes a data-driven approach for creating a SOA, based on microserv

4、ices in an assembly focused production.1 .IntroductionGlobal megatrends such as globalization, urbanization, demographic change, growth of population and sustainable development are not only influencing societies around the world, but also have great impact on manufacturing enterprises and lead to a

5、 paradigm change in all production factors. This includes revolutionary changes in energy and material consumption, staff and capital circulation as well as massive demand movements towards emerging markets and developing countries. It is expected, that by 2025 developing countries will account for

6、half of the global consumption 1. Thus, addressing various markets will be far more a key challenge than facing demand problems. Products for developed countries need to be highly individualized, while products for emerging markets need to be adapted to regional needs including functionality, design

7、 and costs. In addition, there is a trend to shortened innovation cycles. This leads to an increasing complexity of the markets as well as a rise of product variants while quantities per product and variant are decreasing 2. The proposed solution for these challenges from an IT perspective is the co

8、ncept of service-oriented architectures (SOA) and microservices. While a SOA addresses challenges of manufacturing enterprises, their implementation introduces new challenges. Among these challenges are the architecture design in terms of size of the microservices or theirErl T. Service-oriented arc

9、hitecture : concepts, technology, and design. 1. New Jersey:Prentice Hall; 2005.Mazzara M., Meyer B. Present and Ulterior Software Engineering. 1. Cham: Springer International Publishing; 2016.Lewis J., Fowler M. Microservices - a definition of this new architectural term, 2014.f 16 Elmasri R., Nava

10、the S. Fundamentals of database systems. Boston: Pearson/Addison Wesley; 2007.Schel D., Henkel C., Stock D., Seidelmann J. Manufacturing Service Bus: an Implementation. 11th CIRP Conf. Intell. Comput. Manuf. Eng., 2017.附錄B外文翻譯一譯文局部 生產微服務的挑戰 1.介紹全球化、城鎮化、人口變化、人口增長、可持續開展等全球性大趨勢不僅影響著世界 各國社會，而且對制造業企業也產生了

11、巨大影響，導致所有生產要素的范式轉變。這包括 能源和物質消費、員工和資本流動的革命性變化，以及向新興市場和開展中國家的大規模 需求流動。預計到2025年，開展中國家將占全球消費的一半。因此，應對各種市場的挑戰 將遠遠大于面對需求問題。興旺國家的產品需要高度個性化，而新興市場的產品需要適應 區域需求，包括功能、設計和本錢。此外，有縮短創新周期的趨勢。這導致市場的復雜性 增加，以及產品變體的增加，而每個產品和變體的數量都在減少。從IT角度為這些挑戰提 出的解決方案是面向服務的體系結構(S0A)和微服務的概念。當S0A處理制造企業的挑戰 時，它們的實現引入了新的挑戰。這些挑戰之一是根據微服務的大小或

12、它們的編排和集成 進行體系結構設計。因此，本文提出了一種在工業生產環境中如何克服IT體系結構設計和 實現的挑戰，從而從微服務中獲益的方法。2.生產系統中的挑戰信息和通信技術(ICT)將是為描述的制造挑戰的關鍵推動者。大局部創新將發生在企 業。一個傳播解決方案，解決日益增長的市場復雜性同時，企業內部信息通信技術的復雜 性也在不斷增加。智能工廠，下一個進化階段的分形工廠。網絡物理系統(CPS)可以構建分 散的系統而自治網絡一一比方分形一一那么是自組織的和自優化。自治和分權的程度隨著復 雜度的增力口而增力口 。為了使這些開展成為可能，制造業就是其中之一，正在經歷著從傳統到根本的轉變。 面向服務的單片

13、系統自動化金字塔，也稱為Everything-as-a-Service (XaaS) o這個范例 描述了一切，無論物質上的或virtual,是作為服務提供的，源自于三個主要的云計算服 務層Software-as-a-Service (SaaS) 平臺即服務(PaaS)和基礎設施即服務(laaS)。. 1傳統的制造業傳統制造業的特征是在ISA-95中定義的層次結構，通常被描述為自動化金字塔。自動 化金字塔分為三個層次:運營車間層、戰術制造執行系統(MES)層和戰略企業資源規劃(ERP) 層。在每個級別上執行各種計劃和控制任務。自動化金字塔的每個層次上的工具通常是集 中的大型軟件套件，它們需要在許

14、可證費用上進行大量投資。此外，它們通常是單一的， 并且堅持使用自定義接口，而不是使用開放的標準化接口和通信協議。因此，開發和維護 不同系統之間的接口需要付出很高的努力。對于每個系統的新版本，都需要更新所有對應 的接口，因為它們是各自軟件套件的專有接口。由于這種努力，通常無法實現整體的垂直 集成，尤其是水平集成。由于缺少集成而導致的實時數據的缺乏常常需要對生產控制進行 短期且昂貴的干預。此外，引入新軟件套件的過程是非常不靈活和耗時的，根據用例規范 需要幾個月到幾年的時間。2.2新興的制造概念今天，IT制造業正在經歷由云計算和相關概念等技術支持的根本性變革傳統的自動 化金字塔正在瓦解和制造，它正向

15、服務導向和應用導向開展。軟件套件將按功能劃分為服 務和應用程序，并通過edge、fog計算概念和云平臺等分布式計算方法提供分散化。這些 服務和應用程序可以在網絡中無層次地協調，其中基于開放標準的服務之間的通信將成為 成功的關鍵因素。這種層次結構的克服也允許實時信息的通信。.微服務為了介紹微服務的概念，我們首先將其與最明顯的替代方案進行比擬:單片體系結構。 3. 1整體架構短語單片機是用來描述由一塊組成的軟件應用程序。在2.1節中介紹的傳統制造IT通 常使用這種方法。該體系結構設計用于僅在一個計算實例上運行。這可能運行多個進程, 這些進程分布在多個cpu上，但都共享相同的操作系統和硬件。如果系統

16、到達容量峰值, 那么需要完全復制。此過程可能由連續部署系統自動執行。主要缺點是缺乏靈活性。例如， 如果一個實例無法處理多個用戶，那么單片系統就缺乏所需的水平可伸縮性。相反，它必 須垂直縮放。3.2服務導向式架構通常，微服務體系結構是SOA,如第2. 2節所介紹的那樣加以利用。SOA中的服務是一 個軟件組件，它提供與一個業務活動及其特定結果匹配的預定義功能。服務是自包含的, 這意味著它不依賴于外部資源。此服務所需的所有處理都單獨執行。它包括所有需要的資 源，如數據庫等。對于使用該服務的用戶，它顯示為一個黑盒子，只能通過預定義的接口 訪問。它本身可能需要提供特定子功能的底層服務。依賴于一組服務的服

17、務也稱為聚合服 務。. 3微服務架構微服務指的是一種新的軟件體系結構。我們的目標是對該體系結構的屬性進行概述。 核心概念是將應用程序細粒度分解為此類微服務。雖然SOA引用了將功能封裝到單獨服務 中的一般思想，但是微服務還將此功能的規模指定為smallo 3. 4設計理念服務是圍繞業務功能組織的。這允許圍繞系統的關鍵功能而不是預定義的組件進行開 發。服務實例彼此獨立。這適用于整個生命周期，包括開發、部署和維護。微服務依賴于 松散耦合的輕量級通信協議。這意味著服務不直接通信，而是使用獨立定義的接口。這減 少了服務之間的依賴關系，并要求企業服務總線(enterprise service bus, E

18、SB)作為集 成層。分散數據存儲意味著微服務體系結構不再依賴于一個中央數據庫，而是跨服務實例 分割數據存儲。這同樣適用于其他資源，比方計算性能。3.5效益基于微服務體系結構的系統可以更容易地適應不斷增長的容量需求。此屬性通常稱為 水平可伸縮性。如果與前面提到的整體架構相比，這一點尤其明顯。在微服務體系結構中， 可以根據需要復制每個組件以實現負載平衡。這使得對需求的反響到達峰值更快，并能更 精確地處理需求。此外，這種模塊化還使系統對故障具有魯棒性。如果一個微服務遇到錯 誤，系統的其他局部仍然可以獨立運行。使用自動部署，錯誤的服務可以自動替換。通過 保持關鍵服務的備份實例運行，替換也可以預先發生。

19、由于服務是獨立的，因此引入了技 術堆棧和編程語言中的靈活性。任何微服務都可以用該語言實現，并使用最適合提供其功 能的庫。.結論當前的大趨勢(如全球化、人口變化、人口增長)迫使制造企業接受生產范式的變化, 以滿足新的需求。其中一個范例更改是放棄單一的軟件系統，轉而支持SOA和XaaS的概 念，后者支持企業創立具有增強的可伸縮性、健壯性和靈活性的生產系統。SOA的一個特 定概念是將服務設計為微服務，以便不僅封裝功能，而且保持服務的小尺寸。微服務尤其 提高了整個系統的水平可伸縮性和模塊化/健壯性。為了獲得最適合服務的大小，引入了 datadriven設計方法，該方法從創立總體數據結構和相關業務流程建

20、模開始。在下一步中, 整個數據結構被劃分為分配給微服務的邏輯單元。單元的大小取決于靈活性和健壯性的需 求，以及單個服務的資源消耗水平和向所有參與者分配的電力負荷。例如，如果微服務的平均大小很小，為了執行業務流程，連接所有服務的通信通道的負載將會更高，因為必須 在服務之間交換更多的數據。相比之下，如果服務更大，單個服務上的通信將更少，但負 載將更多，因為每個服務都必須執行更多的任務。orchestration and integration. Thus, this paper presents an approach of how to overcome challenges of IT arc

21、hitecture design and implementation in industrial production environments to benefit from microservices.Challenges in Production SystemsInformation and communication technologies (ICT) will be a key enabler for the described challenges of manufacturing enterprises, where most of the innovations will

22、 take place. A propagated solution addressing rising market complexity as well as rising complexity within companies by ICT is the smart factory, the next evolutionary stage of the fractal factory. Cyberphysical systems (CPS) can build decentral and autonomous networks - like fractals - to selforgan

23、ize and self-optimize. The level of autonomy and decentralization rises with increasing complexity 2,3.To enable these developments, manufacturing IT is undergoing a fundamental change from the traditional automation pyramid of monolithic systems to serviceorientation, also described as Everything-a

24、s-a-Service (XaaS). This paradigm describes that everything, no matter if physical or virtual, is offered as a service and originates from the three 2017 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license ( :/creativecommons.Org/licenses/by-nc-nd/4.0

25、/), Peer-review under responsibility of the scientifi c committee of the 11th CIRP Conference on Intelligent Computation in Manufacturing Engineering 168 Benjamin Gotz et al. / Procedia CIRP 67 (2018 ) 167-172 main cloud computing service layers Software-as-a-Service (SaaS), Platform-as-a-Service (P

26、aaS) and Infrastructure-as- aService (laaS) 4. Table 1 summarizes and the following chapters describe the ongoing changes in manufacturing IT.Traditional manufacturing ITTraditional manufacturing IT is characterized by a hierarchical structure defined in ISA-95 and often depicted as the automation p

27、yramid 5. The automation pyramid is divided in three levels: the operational shop floor level, the tactical manufacturing execution system (MES) level and the strategic enterprise resource planning (ERP) level on top. Various planning and control tasks are performed on each level 6.Tools on each lev

28、el of the automation pyramid are usually centralized large software suites which require a significant investment in license fees. In addition, they are often monolithic and stick to self-defined interfaces instead of using open standardized interfaces and communication protocols. Therefore, the dev

29、elopment and maintenance of interfaces between various systems requires a high effort. With each new version of a system, all corresponding interfaces need to be updated because they are proprietary to the respective software suites. Due to this effort, a holistic vertical and especially horizontal

30、integration is usually not realized. This lack of real-time data caused by the missing integration often requires short-term and expensive intervention to production control. Furthermore, the process to introduce new software suites is very inflexible and time-consuming, taking months to years depen

31、ding on the use case specifications 2,6,7.Emerging concept for manufacturing ITToday, the manufacturing IT is undergoing fundamental changes enabled by technologies such as cloud computing and associated concepts. The traditional automation pyramid is dissolving and manufacturing IT is moving toward

32、s serviceorientation and app-orientation 4,8.Software suites will be divided by functionality into services and apps, decentralization offered by distributed computing approaches like edge, fog computing concepts and cloud platforms. These services and apps can be nonhierarchically orchestrated in n

33、etworks, where communication between services based on open standards will become a key factor for success. This overcoming of hierarchical structures also allows for communication of real-time information 6,9.Many manufacturing companies have noticed this shift to service-orientation and have start

34、ed to build their own cloudbased platforms. Examples are the Bosch loT Suite, GE Predix or Siemens Mindsphere. However, most of these platforms are tailored around the products and services offered by the company and lack interoperability with other platform providers. In contrast, there are platfor

35、ms such as Virtual Fort Knox 10 or the Fraunhofer initiative Industrial Data Space 11 following a federative approach to enable independent software vendors to participate in the ecosystem and to prevent vendor lock-in effects.MicroservicesTo give an introduction to the concept of microservices, we

36、compare it in the following first to the most obvious alternative: the monolithic architecture.Monolithic ArchitectureThe phrase monolithic is used to describe a software application consisting of one piece. Traditional manufacturing IT, as introduced in section 2.1, uses this typically. The archite

37、cture is designed for running solely on one computational instance. This may run multiple processes which are distributed across multiple CPUs but all share the same operating system and hardware.If the system reaches a capacity peak, it needs to be duplicated completely. This process might be execu

38、ted automatically by a continuous deployment system. The main drawback is the lack of flexibility. For example, if a number of users is reached that cannot be handled by one instance, a monolithic system lacks the required horizontal scalability. Instead, it has to be scaled vertically. 3.2. Service

39、-Oriented ArchitectureGenerally, a microservice architecture is a SOA, utilized as introduced in section 2.2. A service in a SOA is a software component delivering one predefined functionality matching one business activity and its specific results. The service is self-contained which means that it

40、does not rely on external resources. All processing required by this service is performed in itself. It includes all required resources like databases etc. To consumers using the service it appears as a black box to be accessed only via predefined interfaces. It may itself require underlying service

41、s providing a certain sub-functionality 12. A service which relies on a set of services is also called aggregated service 13.Microservice ArchitectureMicroservices refer to a new software architecture. We are aiming to present an overview of the properties of this architecture. The core concept is a

42、 fine-granular decomposition of an application into such microservices. While SOA refers to the general idea of encapsulating functionalities into separate services, microservices additionally specify the scale of this functionality as small 14.ConceptThe services are organized around business capab

43、ilities. This allows the development around key capabilities of the system instead of predefined components. The service instances are independent from each other. This applies to the full life-cycle, including development, deployment and maintenance. Microservices rely on loosely coupled, lightweig

44、ht communication protocols. This means that services do not communicate directly but rather use independently defined interfaces. This reduces the dependencies between services and requires an enterprise service bus (ESB) as an integration layer. Decentralized data storage means that instead of rely

45、ing on one central database, a microservice architecture splits data storage across service instances. The same applies to other resources such as computational performance 15.BenefitsSystems based on a microservice architecture can adapt to rising capacity demands more easily. This property is comm

46、only referred to as horizontal scalability. This is especially visible, if compared to previously mentioned monolithic architectures. In a microservice architecture every component can be duplicated for load balancing as required. This makes the reaction to demand peaks faster and can handle the dem

47、ands more precisely. Furthermore, this modularity also makes the system robust to faults. If one microservice encounters an error, the rest of the system can still function independently. Using automated deployment, the faulty service may be replaced automatically. The replacement can also happen pr

48、e-emptively by keeping backup-instances of critical services running. Because the services are independent, a flexibility in technology stack and programming languages is introduced. Any microservice can be implemented in the language and use the libraries that fit best to provide its functionality.

49、Proposed SolutionApproachThe proposed solution for designing microservices in production is based on a data-driven approach. This approach needs a clear picture of the data structure as well as the business processes applied in the company. Therefore, it is recommended to identify all relevant entit

50、ies, their attributes and relationships as well as to visualize them. The process is similar to creating database designs by means of Entity Relationship (ER) modeling 16 (see Fig. 1). Based on that overall structure, logical units have to be created which will be managed by one microservice. The si

51、ze of those logical units depends on the need of flexibility and robustness of the overall system as well as the frequency of data exchanged between those units.The frequency of data exchange between logical units is an important key figure indicating whether two units should be combined to one micr

52、oservice. The reason for that is justified by the use of an ESB for communication between all services (see Fig. 2). In case services have a small size, the load of the communication channel will rise unnecessarily because data has to be sent between services rather than within one service. Addition

53、ally, the effort for creating the routes between the services will rise. In order to estimate the frequency of data exchange between services, it is important not only to be aware of the data structure but also the behavior of the system. The business processes implemented in the company mainly infl

54、uence the behavior from which the data exchange rate of services may be derived. Consequently, choosing the right size of microservices is an optimization problem with flexibility, robustness and resource consumption as criteria.Data structure of microservicesAfter agreeing on a first draft of servi

55、ces, the data structure of each service has to be derived from the overall data structure. In order to retain relationships that exist between entities of different services, measures of identifying entities across service borders have to be introduced. A basic identification measure is using unique

56、 keys of entities. This keeps the level of redundancy low and minimizes the effort for keeping data up to date.For example, a Service A“ that stores all data about a class of entities has to provide an application programming interface (API) for accessing entities data from other services. In order

57、to address one specific entity, a Service B has to send a request to Service A“ containing the unique key of the requested entity. As a result, Service A“ provides all data about the requested entity in a predefined manner to Service B”. By doing so9 Service B“ will always get the latest dataset of

58、an entity without storing it by itself.The disadvantage of this approach is that each request will strain the integration layer which transports data from one service to another. In order to reduce the communicational load, a subset of data may be stored in addition to or instead of the unique key t

59、hat is stored in Service B”. This leads to increased redundancy and the data integrity is no longer guaranteed. Thus, this method is only recommended if data does not have to be up to date for each request or measures for updating redundant data are introduced among related services. Furthermore, th

60、e raised level of redundancy increases the amount of required storage. Finally, it depends on the use case which approach should be selected and whether the depicted disadvantages are relevant for the implementation.Business processes and routingBased on the overall data structure, a sub-structure f