这是一个创建于 2070 天前的主题，其中的信息可能已经有所发展或是发生改变。
- 小白不太明白 如果要说理解 我只能简单类比于服务器的负载均衡
- 希望 V 站的老师们能各抒己见 谈谈自己的认知咯
- 纯粹是交流 以和为贵咯 嘻嘻 ：）可爱
 |
1
boris1993 2019-03-30 01:31:08 +08:00 via Android
今天刚听前辈谈了下微服务，说下我的理解
拿商城举例，传统架构是把商城作为一个整体看待，简单来讲就是一个 war 包部署进一个 tomcat 示例 微服务则是把应用按照功能，拆分成较小的，可以独立运行的模块，比如拆分成用户、登录、下单、搜索等几部分，模块之间用 HTTP 或 RPC 协议通信 |
 |
2
ferock 2019-03-30 01:37:09 +08:00 via iPhone
各种名词只是新瓶装旧酒。有一些公司 boss 喜欢搞的自己很高大上，于是就喜欢吹嘘这些名词，举个例子…生态化反…
囧 rz … |
 |
3
hilbertz 2019-03-30 01:42:03 +08:00
原来 1 个人干的活，变成 10 个人干的活
|
 |
4
lynskylate 2019-03-30 01:50:59 +08:00 via Android  3
不同人看微服务都不一样吧。在我看来，微服务以服务为基础单元，配以 rpc 为核心的一系列中间件进行开发的一种方式。
主要是传统的单体架构应用在面对用户增长时难以进行横向扩容，应用局部存在性能问题，却只能扩容整体。 单体架构在进行开发新功能时也会造成整体代码的腐化，包括难以测试，难以维护。 对于小公司来说微不微服务没啥必要，能用最重要。 |
 |
5
akira 2019-03-30 02:08:06 +08:00
面向对象会吧 类比一个个对象更合适
|
 |
6
just1 2019-03-30 02:27:34 +08:00
把一体机变成可以自由装配的台式机
|
 |
7
a123321456b 2019-03-30 02:34:57 +08:00 via Android
性能不够怎么办 加服务器配置
还不够怎么办 每个服务器少做点事 几个服务器拼起来组成整个系统 |
 |
8
Luckyray 2019-03-30 03:44:09 +08:00 via iPhone
简单说就是模块化
|
 |
10
no13bus 2019-03-30 07:26:07 +08:00
首先你需要区分单体服务，微服务，soa 服务这几个
|
 |
11
rogwan 2019-03-30 09:08:59 +08:00 via Android
用企业部门打比方，传统组织机构是研发 销售 行政部这样，微服务是各种 CXO。
|
 |
13
zhuzhibin OP @lynskylate 哈哈 的确是 如果这么理解 前后端的分离 算是模块化么
|
 |
16
lhx2008 2019-03-30 09:47:55 +08:00 via Android
细粒度服务（不是一个公司一个大 jar 包），自动化流程（测试，发布，扩展等），完整的基础设施（配置中心，路由，熔断器，服务治理，链路监控，网关），轻量级服务通信（ rpc，restful ），和服务数量相对应的开发人员（公司就几个人拆服务没意义）
|
 |
18
opengps 2019-03-30 10:32:45 +08:00 1
可以理解成单元，微服务就是把系统的拆分单元化，这样将来需要扩容时候，可以轻松知道只需要扩容哪个或者哪几个单元。
举例说：某系统从 100 用户涨到 100000 用户，可能只是某个核心内容节点的读取量上升，那么其实只需要将这个读取内容的单元做负载均衡扩容 |
|
19
opengps 2019-03-30 10:33:47 +08:00
微服务，云架构，都是给将来访问量增加所打下的基础，合理的设计，面对范文压力将来不用推到重新做
|
 |
20
txwd 2019-03-30 10:45:44 +08:00
上面的大神说得那么专业，说一下我的理解：就是把功能或模块部署一套或多套，再通过网关串起来。这东西开发成本和维护成本很高，要看场景用。仅是我的理解。
|
 |
21
edgnoz 2019-03-30 11:09:29 +08:00
对于绝大多数企业来讲，加个云啊微啊什么的，显得高大上
|
 |
22
willyang 2019-03-30 11:16:34 +08:00 via Android
划分业务模块的思想吧
|
|
23
opengps 2019-03-30 11:21:23 +08:00
临时写了篇博客，《使用微服务和云架构应对系统扩容》 https://www.opengps.cn/Blog/View.aspx?id=279
结论: 微服务的价值：在于将来访问量上升时，精准调控某一个瓶颈点的功能，主要属于开发层面的储备 云架构的价值：在于访问量上升时，直接增加服务器数量扩大系统承载阈值，主要属于运维层面的储备 |
 |
24
Cyanic 2019-03-30 11:29:17 +08:00 via iPhone
解耦合从代码层面进化到业务功能模块层面，模块间采用 rpc 通信，这是我的个人理解
|
 |
25
HuasLeung 2019-03-30 14:34:48 +08:00 via Android
“分而治之”
|
 |
26
huijiewei 2019-03-30 14:43:55 +08:00
微服务容易扩容
看你项目决定 |
 |
27
hoyixi 2019-03-30 15:20:32 +08:00 1
SOA 老调新弹
|
 |
28
zzl22100048 2019-03-30 17:41:30 +08:00
小而自治，单一职责
|
 |
29
wc951 2019-03-30 18:01:26 +08:00 via Android
去中心化 soa
|
 |
30
limuyan44 2019-03-31 01:59:08 +08:00 via Android
就是功能拆分。。
|
 |
31
hsuehsen 2019-03-31 09:09:57 +08:00
1. 原生支持高可用、集群（分布式）、高并发，可根据流量水平扩展
2. 服务拆分，说白了就是解耦 服务之间通过接口的方式提供服务，所以开发、维护成本低。因为就是开发全新的一个子系统，没有历史负担，可以根据团队技术栈，选择全新的语言与开发框架 3. 网关作为入口，可做限流、授权（ api 级别）、分发等，共性的可以都放在网关，容易维护 很多人都说小公司用不用微服务无所谓。只是我的观点恰恰相反，小公司更应该用微服务，因为只要一开始框架搭好，原生就支持高可用、高并发——这就可以省很多事情。 在公司业务扩展的时候，选择技术方案与招人，也可以灵活很多；不需要特定的技术栈 |
Select Language