First understand the evolution of technical architecture, application architecture monomer -> Vertical Application Architecture -> Distributed architecture -> SOA -> Micro Services
Micro Services and SOA
SOA: Service-Oriented Architecture
advantage:
Extraction of public service functions, improve development efficiency for different services clustered deployment, solve the system pressure. ESB / DUBBO reduce system based coupling
Disadvantages:
Extracting service large particle size, high service provider interfaces with the caller to the service coupling.
What is micro-services?
In short, the development of micro-services architecture style this way, is the development of a set of small service way to develop a stand-alone application system. Each small service runs in its own process, and often uses a lightweight mechanism for HTTP resource API to communicate with each other. These services build around business functions, and through automatic deployment mechanism for independent deployment. These micro-services can be written in different languages, and may use different data storage technology. These micro-management services we concentrated only do the minimum.
From a technical dimension to understand:
Core micro-service is the traditional one-stop applications, according to a split business into a service, completely decoupling, each serving a single micro-service business functions, a service to do one thing, from a technical point of view is a kind of small and independent process, the concept is similar to the process can start on its own or destroyed separately, have their own independent database
Micro Services and Micro Services Architecture
Micro Services
Emphasized that the size of the services, it is concerned that a certain point, is a service application specifically address a particular issue / offer corresponding service floor, a narrow point of view, can be seen as IDEA in a micro-service engineering, or moudel.
Micro Services Architecture
A new form of architecture, proposed by Martin Fowler in 2014. It calls for a single application into a set of smaller services, each running in its own separate process, co-ordination between services, another configuration provides ultimate value to users. The use of lightweight communication mechanism between the services communicate with each other, each service around the specific business to build, and can be independently deployed to the production environment, should also be avoided unified, centralized service management mechanism for specific terms of a service should be based on the business context, select the appropriate language, tools to build them, can have a very lightweight centralized management to coordinate these services, you can use a different language to write services can be using different data storage;
微服务的特点：
1.每个微服务可独立运行在自己的进程里
2.一系列独立运行的微服务共同构建起了整个系统
3.每个服务为独立的业务开发，一个微服务一般完成某个特定的功能，比如：订单管理，用户管理等。
4.微服务之间通过一些轻量的通信机制进行通信，例如通过REST API或者RPC的方式进行调用。
微服务的优点：
每个服务足够内聚，足够小，能聚焦一个指定业务功能。
开发简单，开发效率提高，一个服务专一的只干一件事， 易于开发和维护。
微服务是松耦合的，是具有功能意义的服务，无论是在开发阶段或部署阶段都是独立运行的，启动较快。
技术栈不受限，微服务能使用不同的语言开发。
局部修改容易部署
易于和第三方继=集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如bamboo，Hudson
微服务只是业务逻辑的代码，不会和html，css或其他界面混合
每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一的数据库
微服务带来的挑战
运维要求较高(多服务运维难度，随着服务的增加，运维的压力也在增大)
分布式的复杂性
接口调整成本高
系统部署依赖
系统集成测试
性能监控
微服务设计原则
单一职责原则
服务自治原则
轻量级通信原则
接口明确原则
微服务技术栈
| 微服务条目 | 落地技术 |
| 服务开发 | SpringBoot，Spring,SpringMvc |
| 服务配置与管理 | Netflix公司的Archaius ,阿里的Diamond等 |
| 服务注册与发现 | Eureka, Consul , Zookeeper等 |
| 服务调用 | Rest, RPC , gRPC |
| 服务熔断器 | Hystrix, Envoy等 |
| 负载均衡 | Ribbon ， Nginx等 |
| 服务接口调用(客户端调用服务的简化工具) | Feign等 |
| 消息队列 | Kafka, RabbitMQ, ActiveMQ等 |
| 服务配置中心管理 | SpringCloudConfig, Chef等 |
| 服务路由(API网关) | Zuul等 |
| 服务监控 | Zabbit, Nagios, Metrics, Specatator等 |
| 全链路追踪 | Zipkin, Brave, Dapper等 |
| 服务部署 | Docker,OpenStack,Kubernetes等 |
| 数据流操作开发包 | SpringCloud Stream(封装与redis，rabbit,Kafka等发送接收消息) |
| 事件消息总线 | SpringCloud Bus |
如有不同意见，欢迎留言指正。大家一起进步呦！！！
