background
Service-oriented architecture is the most popular concept at present. When we talk about service-oriented architecture, the first thing that comes to our mind is that in Internet applications, the architecture model of interconnecting calls between services and services is adopted. RESTful, Json, and Webservice must be inseparable from these words. But from my personal understanding, service-oriented should be a concept of architecture design. Compared with the previous modular design idea of very process, service-oriented is the evolution of modularization. From the original large-scale modules, it has been transformed into a service (unit) focusing on specific businesses and functions.
Any module is a relatively complete and independent system, from front-end view, to business processing, data model processing, and data storage. They are independent of each other and do not interfere with each other. They are independent chimneys. The service-oriented architecture idea has changed the structure of the chimney. The idea that has been cross-cut, the original chimney has been cut. For the functions on the aspect, the unification is realized by the function provided by the service.
Correspondingly, in any system or module, this cross-cutting idea can be used for reference, and the module can be cross-cut to divide services by function.
overall design idea
Architecture Microservice Design
From the perspective of the architecture, in accordance with the idea of microservices, the concept of services is first defined, and services are layered. Each layer is composed of services that provide different functions, changing from the original modular understanding to the service-oriented concept.
In addition, the concept application of microservices is particularly emphasized here. From the traditional modular design style to the service-oriented design style, it is a transition. From services to microservices is another architectural style change and a development model change. Microservices emphasize a micro, the same are services, and microservices emphasize fine-grained services. The cycle process from the scale of the function, the investment in development, to the actual delivery. Micro means faster, but also means more microservices are developed and delivered in parallel. From the perspective of the development pipeline, it is beneficial to the multi-pipeline operation mode.
Through the pipeline operation, the service delivery efficiency is improved, and the function decoupling is further achieved. Here, the author tries to illustrate the application process of the microservice concept based on the development and design of an Eclipse plug-in project.
The following figure is the design diagram of the plug-in project based on the modular design level0:
这是一个非常常见的基于功能模块的系统设计方式，按照不同的功能划分到相应的功能模块。在该插件工程中，应用数据都是存储在XML文件中。因此，存储模块直接利用了第三方开源的xml处理模块。而在数据模型处理模块，则是根据业务view的视图需要，以前端view的功能进行模块的划分。不同的视图，需要提供不同模型的数据。在数据模型处理模块，既会有单一模型的数据处理，也会涉及到多数据模型的处理。而这些功能都是按照前端的需求进行涉及和划分，是一种自前而后的设计。从展示需求端入手，设计底层的实现往往是一种较快捷，也较容易理解的一种设计思考方式。
但是，随着业务功能的深入，对数据模型处理的功能复杂度也在不断上升。尤其是因为模型的设计会随着功能的深入而不断的被修改，也就导致了数据模型处理模块不断的变更。而且，由于模型没有被单独的封装到一个处理模块中，导致变更的修改会有多出。
例如，该项目的xml模型的依赖关系如下图：
对Offering模型的实例化数据的处理，会附带着对Product和Plan的数据处理。在原有模块化的划分方式下，设计并提供一个Offering模型的处理是合理的。但是也存在一定的隐患，就是对Product和Plan，甚至是Property的数据处理都包含Offering的模型处理中。因此，当存在Product或Plan甚至是Property的模型变更、功能调整都会引起Offering模型处理模块的变动，也就是说Offering模型处理的功能不够“单一”。Offering模型“本身”没有调整，却因为它包含的模型调整而变更。
因此，一种可行的微服务化得设计思路（注，这里所谓的服务并不是特指web服务。而是从本质上来说，它们的设计思想是相通的），就是按照模型独立来拆分“微服务”：
将原来的数据模型处理层进行重新的设计和划分，一部分拆分为细粒度的模型服务，一部分拆分为细粒度服务组合后的业务功能服务。也就是说，会有组合服务和原子服务（相对而言）。展示层View则保持不变，微服务化尽量保持原有接口兼容，不会引起对上层的变动。
由于，原有模块化提供的功能接口保持不变。而服务接口又势必会引起对这些接口的冲击，这里可以借助Proxy设计模式，通过代理封装内部变化，并且同时发布新的业务服务接口，并标记原有的功能接口过期。
服务接口和实现的设计思路
从本质上来说，模块化的设计进一步发展就是服务化，而发展到极致（追求功能单一）就是微服务化。在本例中，按照服务化的设计思想，对服务设计主要分为接口设计和实现设计。服务的接口定义表明了该服务对外的契约，应该是相对稳定的。但是随着业务的深入发展，接口也会进行变动，为了避免接口变动对外部造成的影响。接口也需要有版本定义，而接口的实现则更是如此。实现更加的灵活多变，通过不同的实现类来避免这种情况的发生。如下的java package包的设计就是这种思路的一种体现：
例如：
ModelServiceLayer.OfferingModelService.v1 ：表示为模型服务层的Offering模型服务的v1版本定义。
ModelServiceLayer.OfferingModelService.v1.impl： 表示为Offering模型服务的v1版本的实现。
ModelServiceLayer.OfferingModelService.v2 ：表示为模型服务层的Offering模型服务的v2版本定义。
ModelServiceLayer.OfferingModelService.v2.impl： 表示为Offering模型服务的v2版本的实现。
注：对于package的划分在实际开发中存在很多的方式，例如：微服务层名.版本.微服务名，这种方式是以版本为维度，将同一版本下的微服务集中在一起。这种方式的好处的，管理直接。如果是按照版本运作，则更适合这种模式。不同的版本由不同的团队独立负责。
对于接口版本的定义，完全可以实现向前兼容。而兼容的做法是在新版本接口中保留原有版本接口的定义，而新版本接口定义的实现可以通过代理方式直接调用之前版本的实现。
如上图，对于v2版本接口定义中来自v1版本的，在v2版本接口的实现直接委托v1版本接口定义的实现。
如此，版本和实现可以随需求和功能一并演进。按照微服务化得思路，在开发和构建时，每天可以根据当前微服务的开发进度进行版本功能合并和出包。外部的对微服务只依赖于具体的接口实现，当微服务构建完成后，既可以直接进行集成。同时，利用IoC容器（成熟的spring即可），服务的实现可以注册到IoC容器中，并提供服务接口的不同实现。同时，也就把IoC容器作为一种服务中心来使用。在当前项目的需求背景下，把IoC容器作为服务控制和注册的中心，并且已经满足当前的需求。后续可以在根据情况，对服务的控制和注册能力的提升。
如下例，OfferingModelService依赖于StoreService的服务接口，而StoreServiceXmlImpl和StoreServiceDBImpl则分别实现了StoreService的接口定义，通过Spring的配置可以表示为：
在接口定义好之后，实现可以先注册一个Mock的实现，对外不提供任何的功能实现。随着实现的不断完善，在完成impl1之后，可以替换原先的注册。这时可以提供部分的功能实现，未提供的功能对外仍然是调用失败的。Impl2可以是另外一部分实现，可以通过委托调用impl1中已经实现的功能。如此，就可以提供一种并行开发的模式，从而提升开发的效率。
在这种思路下，更进一步。一个接口的定义实现就可以被拆分成不同的Function实现类，分别实现不同的Function，最后统一由impl进行集成。如下图：
其他思考
在有了微服务化的思路后，对现有工程重构后，如何对这些微服务，以及它们之间的依赖关系进行管理，就变得很重要了。以微服务作为最基本的单元进行跟踪：需求拆分、开发、测试、验证、发布，最后统一进行集成验证和打包发布，就是一个具有挑战性的任务。尤其是跟踪微服务的进度、集成后的功能进度等。这里，可以构建一个微服务看板的视图，通过这个看板视图了解到以上信息。
首先明确，一个微服务是可以进行独立开发、测试、验证和发布的。微服务的测试，可以由使用该微服务的开发人员提供测试的元素代码，由测试人员通过进一步的架构完善。最后，作为微服务在构建环境上的测试用例。通过微服务看板，每天可以跟踪微服务的当前进展（开发、测试、发布的状态），跟踪开发进度。