Currently large or very large enterprise IT platform are chimney system architecture, the reason is to cater to business development within the enterprise constantly create a variety of systems, but also lead to duplication of functions among the construction and maintenance of a system of duplication of investment. Repeated investment not only consume the human and financial resources as well as time. But the cost of interaction and collaboration between the open chimney systems is high, major companies had to use ESB products to build enterprise service bus to solve the problem of the interaction between the various systems.
However, with the development and iterative business, the company's business structure is gradually changed, only to get through the interaction and collaboration among the system issues is not enough, need to gradually integrate the various existing systems, allowing companies from the strategic, organizational, terms of systems, processes and services such as ongoing iterations, improve the business structure and the operation mode, enabling enterprises to achieve current and future goals, and then according to the needs of enterprise business model and establish a systematic, standard, then business processes and intelligence information platform for enterprise business blueprint iteration.
If not enough just to get through the interaction and collaboration between the various systems, it is up to the individual how to integrate the existing system?
First, we have to analyze the aid ESB "center" of the service infrastructure shortcomings, one: ESB "centralized" architecture of all service calls and service provider interaction between those who have to go through this central point, and the center point capacity is
Difficult to expand, resulting in this center will become a bottleneck; Second: the existing system is a single system based on SOA architecture, doing business process orchestration, application integration aspects of performance is very good, but with the development of business systems is complicated, high coupling module, associated dependent complex, indeed affect the whole body, is not conducive to business innovation and iteration; Third: repeat multiple systems in service can not be shared, resulting in a multi-code data is not synchronization and other issues, there are hidden dangers.
Secondly, we look at the success of "medium and large units, small foreground" information technology cases.
2015 Alibaba Group launched a strategy in Taiwan, the goal is to build a large Internet data in line with the times, innovative, flexible "medium and large units, small reception" mechanism, that is, as the front desk front-line business will be more agile, faster applicable to the changing market, and the station operational data collection capabilities, product technical capacity of the entire group, the formation of strong support for each of the front-office. Overall reads as follows:
"Dazhong Taiwan, small reception" architecture focused on shared business service layer, business shared services team, a separate team to do, but also more conducive to precipitation business, reduce development costs and improve the efficiency of research and development. Breaking the barriers of products, systems prior to the data between now have to look for shared service centers to data, shared services center to provide a unified, standard data. Reducing the cost of inter-system interaction between, teamwork. Standing on the shoulders of giants. New product development regardless of existing things before, you can quickly hatch new products, low cost of trial and error, product innovation, the courage to embrace change, the competition is very difficult to recover the original, and now the equivalent of a competitor's product manager for non-stop provides us with new ideas. Sustainable development, technical and operational capacity capable of accumulated precipitation.
Relations "medium and large units, small reception" and micro services
Micro service reflects decentralized, distributed natural, medium and large table with a similar strategic thinking, is a specific implementation of the strategy. Existing architects can learn from this model to solve business application itself high concurrency, high availability, operation and maintenance and other problems, but also the existing Internet infrastructure classic, after all, is the result of Ali practiced, in addition to BAT, Uber, Netease, the US group Jingdong and other internet companies have realized much earlier in the micro platform as a service.
Universal service is the micro-enterprise of services by businesses into one single service, enhanced availability, service easy to expand, reduce development costs and reduce the impact on the entire service publishing platform. Micro service is an idea, there are many ways to achieve, companies turn steering system by a single micro-services necessary to consider many issues, such as technology selection, split the business problems, high availability, communication services, service discovery and management, fault-tolerant cluster, configuration management, data consistency problems, Conway's law, distributed call trace, CI / CD, micro-service testing, and deployment scheduling and so on, this is not some simple tricks can resolve.
Micro Services framework must be able to reach With virtualization platform to create demand and adjust the size of the machine, with the expansion of infrastructure automation from one machine to Taiwan, with business monitoring and early warning, abnormal fusing function and so on, the existing framework Dubbo and SpringCloud, Dubbo is the RPC service governance framework, and SpringCloud as registered with the service, ability to find, routing, load balancing and so on.
Micro-services architecture contains:
Since the micro-architecture so good service, which will challenge the monomer system upgrade to the micro-service architecture:
1: How to disassemble Service
使用什么样的方法拆解服务？业界流行1个类=1个服务、1个方法=1个服务、2 Pizza团队、2周能重写完成等方法，但是这些都缺乏实施基础。我们必须从一些软件设计方法中寻找，面向对象和设计模式适用的问题空间是一个模块，而函数式编程的理念更多的是在代码层面的微观上起作用。
Eric Evans 的《领域驱动设计》这本书对微服务架构有很大借鉴意义，这本书提出了一个能将一个大问题空间拆解分为领域和实体之间的关系和行为的技术。目前来说，这是一个最合理的解决拆分问题的方案，透过限界上下文（Bounded Context，下文简称为BC）这个概念，我们能将实现细节封装起来，让BC都能够实现SRP（单一职责）原则。而每个微服务正是BC在实际世界的物理映射，符合BC思路的微服务互相独立松耦合。
二：失败处理的成本
随着服务的数量增加，系统失败的几率会大幅增加。
每一个服务的失败都有可能导致故障。虽然我们的目标是期望每个服务都能够互不依赖，自适应，高度容错，但是必须找到有效的方式来确保服务可用。
因此，处理失败的成本大幅增加。
三：优势资源的竞争
当有成千上万的服务时，资源如何分配？从业务角度分析，哪个服务的优先级高？哪个团队应该优先获得更优秀的资源？包括但不限于优秀的工程师、资金、软件、硬件等等。
任何时候，资源都不是免费的。
当只有几个微服务时，这些问题都不会是问题，但随着服务数量的增加，这种协作与竞争的关系会愈发明显。
四：独立性与技术债
随着微服务的大热，组织中许多人员对微服务过度追捧。
很多人认为微服务对应着松散的组织结构，只要能独立交付，团队可以做任何他们想做的。从技术角度而言，技术日新月异的变化，会产生各种大大小小的技术债，而随着采用微服务化在技术上的多样性，将变得难以维护。
微服务确实意味着自由与独立。但在大规模的组织中，过度的独立性必然带来高昂的管理与维护成本。从工程角度而言，当拥有成千上万的服务时，集中式的管控平台并不像我们认为的那样糟糕，确保大部分团队能使用相同的方式、相同的标准，能够低成本运作。
五：团队的信任危机
作为服务的交付团队的负责人，你可能有必胜的信念。充满豪情壮志，愿意带领团队遵循各种最佳实践、完美的实现所负责的服务。但是，你永远无法保证，依赖的所有上下游团队，也能按照同样的标准实现服务。这是现实。而且，随着服务关系越复杂，依赖越多，出问题的几率越大，信任危机愈发明显。
