Các ứng dụng thực tế của Windows Services là gì? [đóng cửa]

Tôi mới làm việc với Windows Services. Mặc dù tôi đã học cách tạo Windows Services trong VS2010 nhưng tôi muốn biết một số cách thực tế trong đó dịch vụ windows có thể được sử dụng?

Tôi đã cố gắng Googling với bối cảnh hiện tại chỉ để tìm thêm hướng dẫn về cách tạo Windows Services.

EDIT trên Ưu đãi Bounty:

Tất cả các câu trả lời là tuyệt vời nhưng tôi đang tìm kiếm các ví dụ thực tế hơn về các dịch vụ windows và ý nghĩa của chúng? Điều này sẽ giúp các nhà phát triển biết khi nào thì phù hợp để sử dụng chúng với nghiên cứu trường hợp.

Một dịch vụ chạy trong nền, ngay cả khi không có ai đăng nhập vào máy. Bất cứ điều gì bạn có thể tưởng tượng muốn làm mà không cần dựa vào một người để bắt đầu một ứng dụng và nhấp vào nút là một ứng cử viên tốt cho một dịch vụ. Ví dụ: giám sát một thư mục và bất cứ khi nào một tệp được ghi vào nó, hãy xử lý nó theo một cách nào đó. Bất kỳ "máy chủ" nào bạn có thể nghĩ đến - máy chủ web, máy chủ ftp, máy chủ thư - là một dịch vụ và nhiều quy trình nền mà bạn có thể không thường nghĩ tới.

Một số thứ từng được viết là dịch vụ (tệp sao lưu lúc 2 giờ sáng, gửi email nhắc nhở vào lúc 3 giờ sáng, v.v.) có thể được thực hiện tốt hơn như các tác vụ theo lịch trình, có tính linh hoạt rất lớn trên Windows 7 trở lên, nhưng nếu nhà phát triển không bao giờ học chúng, hoặc hệ thống phải hỗ trợ XP, bạn cũng sẽ tìm thấy các dịch vụ thực hiện các loại nhiệm vụ đó.

Các dịch vụ trên Windows về cơ bản là các chương trình chạy mà không cần GUI. Các máy chủ web (như apache), máy chủ cơ sở dữ liệu (như máy chủ mysql & sql), công cụ chống vi-rút và máy chủ ứng dụng / 'phần mềm trung gian' đều là những ví dụ thực tế về các ứng dụng thường chạy dưới dạng dịch vụ. Có thể có máy khách GUI để cho phép bạn tương tác với dịch vụ, nhưng bản thân dịch vụ không có. Nó chỉ chạy 'trong nền', làm việc của nó. Ngoài ra, vì các dịch vụ chạy với quyền người dùng được gán cho chúng, chúng có thể chạy như người dùng được chỉ định của chúngngười dùng có thực sự đăng nhập vào máy hay không. Vì vậy, một máy chủ cơ sở dữ liệu sẽ có quyền truy cập như nhau bất kể người nào đã đăng nhập vào máy vào thời điểm đó, nếu có. Vì vậy, bạn có thể thấy lý do tại sao điều đó lại quan trọng - chẳng hạn, bạn không muốn phải đăng nhập người dùng để duy trì máy chủ web.

Chúng tương đương với Windows (theo cách thực tế nhất) với Daemon trên * nix.

Dịch vụ

Một chương trình, thói quen hoặc quy trình thực hiện một chức năng hệ thống cụ thể để hỗ trợ các chương trình khác, đặc biệt ở mức thấp (gần với phần cứng). Khi các dịch vụ được cung cấp qua mạng, chúng có thể được xuất bản trong Active Directory, tạo điều kiện cho việc sử dụng và quản trị tập trung vào dịch vụ.

Tôi muốn biết một số cách thực tế trong đó dịch vụ windows có thể được sử dụng?

Theo định nghĩa dịch vụ, Window Service và các loại dịch vụ khác thực hiện rất nhiều chức năng. Trong bối cảnh này công cụ tìm kiếm là bạn của bạn .

Các dịch vụ Windows thường được sử dụng khi một ứng dụng cần chạy liên tục. Bạn nên tạo một Dịch vụ Windows để chạy mã nền, không có sự tương tác của người dùng .

Dịch vụ Windows sẽ chạy ngay cả khi không có ai đăng nhập. Dịch vụ Windows có thể bắt đầu chạy ngay khi máy được bật nguồn , điều này lý tưởng để chạy như một máy chủ, ví dụ như máy chủ http. Không ai được yêu cầu đăng nhập.

Ví dụ nếu họ cần:

1. Chờ đợi các yêu cầu đến. (Giống như thông qua điều khiển từ xa hoặc wcf)
2. Giám sát hàng đợi, hệ thống tệp, v.v ... Nếu một chương trình chỉ cần chạy định kỳ, như một lần một ngày. Thông thường dễ dàng hơn để tạo một tác vụ theo lịch trình ..
3. Bất kỳ máy chủ nào chấp nhận kết nối (như thư, web hoặc máy chủ FTP) thường phải là Dịch vụ Windows.

Tôi sẽ sử dụng một dịch vụ vì những lý do sau:

• Bạn không cần phải có một phiên chạy. Điều này tốt cho bảo mật và cũng giảm chi phí trên máy chủ.

• Bạn nhận được một số lệnh quản lý được tích hợp miễn phí
  o Bắt đầu
  o Dừng
  o Tạm dừng
  o Tiếp tục

• Bạn có thể xử lý các sự kiện máy chủ như tắt máy.

Liên kết với thông tin bổ sung về các dịch vụ này:

Tại Asp.net - // TODONT: Sử dụng Dịch vụ Windows chỉ để chạy quy trình theo lịch trình Việc
sử dụng Dịch vụ WIndows là gì

Một chương trình tương tác, như winform hoặc WPF, là thứ bạn muốn người dùng mở, tương tác và đóng. Nhiệm vụ theo lịch trình là thứ bạn muốn chạy trong nền theo thời gian cụ thể - có thể chỉ cần khởi động, làm gì đó và dừng lại. Một dịch vụ Windows là một cái gì đó bạn muốn chạy tất cả các thời gian ở chế độ nền.

Một số ưu điểm của Dịch vụ Windows là nó chạy bất kể người dùng nào đã đăng nhập (hoặc ngay cả khi không có người dùng nào đăng nhập) và nó có thể được thiết lập để bắt đầu chạy ngay khi máy tính khởi động, điều này có thể thực sự hữu ích nếu hệ thống được khởi động lại.

Tôi thường sử dụng các dịch vụ khi tôi phải theo dõi thứ gì đó như thư mục hoặc hộp thư đến email.

Vì bạn đã thêm ghi chú về các ví dụ thực tế vào câu hỏi của bạn, tôi sẽ cung cấp cho bạn một số ví dụ về các dịch vụ tôi đã viết cho các ứng dụng doanh nghiệp (bạn không nói nếu bạn là lập trình viên ứng dụng doanh nghiệp nhưng tôi đoán là hầu hết các lập trình viên C # VS2010) . Tôi nghĩ rằng bạn đang tìm kiếm một ý tưởng về những gì các nhà phát triển không làm việc cho Microsoft có thể viết.

Một dịch vụ theo dõi nhịp tim kiểm tra xem các chương trình khác có còn chạy không (điều này có thể cũng hoạt động như một nhiệm vụ theo lịch trình, nhưng được triển khai như một dịch vụ).

Một dịch vụ viết báo cáo hoạt động thông qua hàng đợi các yêu cầu báo cáo, chạy các báo cáo và gửi chúng đến các máy in khác nhau tùy thuộc vào máy in nào bận. Điều này đã giúp giảm tải một lượng công việc khá lớn từ một ứng dụng cũ và cho phép báo cáo đang chạy được chia sẻ bởi nhiều hộp giá rẻ chạy dịch vụ.

Nó được triển khai như một dịch vụ để nó chạy liên tục, tự động khởi động lại khi khởi động lại và có thể sử dụng giao diện dịch vụ windows tiêu chuẩn để bắt đầu, dừng, tạm dừng, v.v. Ngoài ra, nếu đó là một nhiệm vụ theo lịch trình thì nó cần phải bắt đầu nhận dữ liệu từ các chương trình khác hoặc nguồn liên tục (hàng đợi, tệp, cơ sở dữ liệu) thay vì có sẵn để các chương trình khác gọi (ổ cắm, đường ống).

Phần máy chủ của ứng dụng khách / máy chủ đó cũng được triển khai như một dịch vụ để nó khởi động lại khi khởi động lại, v.v. Có một dự án khác với .exe chạy cùng một chương trình không phải là dịch vụ, để dễ dàng hơn gỡ lỗi trên các máy phát triển.

Tôi hy vọng điều đó sẽ giúp. Các câu trả lời khác là câu trả lời chung tốt hơn, đặc biệt là ý tưởng rằng các tác vụ theo lịch trình có thể dễ dàng hơn để viết và quản lý cho hầu hết các mục đích hiện nay.

Có nhiều ứng dụng thực tế cho một dịch vụ. Một ứng dụng thực tế chính là sự tương tác giữa các chương trình UI và dịch vụ (hoặc daemon trong unix), trong trường hợp này là sự khác biệt giữa máy khách và máy chủ. Một máy chủ nhận được yêu cầu, xử lý yêu cầu và thường gửi trả lời lại. Nói cách khác, nó PHỤC VỤ một yêu cầu. Hãy suy nghĩ về SQLSERVER, IIS hoặc telnet. Một khách hàng, thường sử dụng một máy chủ bằng cách gửi yêu cầu đến máy chủ và sau đó hiển thị hoặc xử lý trả lời. tức là một ứng dụng nhập dữ liệu, một ứng dụng web ... Máy chủ hầu như luôn được cài đặt như một dịch vụ trong windows (hoặc daemon in unix) và máy khách thường chỉ là một ứng dụng bình thường với gui. Có nhiều cách sử dụng dịch vụ phức tạp hơn, nhưng đây là cách bạn có thể sẽ sử dụng nhiều nhất.

Ví dụ: Tôi hiện đang làm việc trên máy chủ video SIP / H323. Nó nhận được yêu cầu từ một ứng dụng sử dụng SDK mà tôi đã viết, xử lý chúng và trả lời lại. Ứng dụng máy chủ video được cài đặt dưới dạng daemon trên máy linux được nhúng (nó sẽ là dịch vụ trên máy Windows nhúng, nhưng ai sử dụng Windows để nhúng) và mọi ứng dụng sử dụng SDK sẽ được coi là máy khách.

Tất nhiên, bạn có thể viết các ứng dụng như vậy và không biến chúng thành một dịch vụ. Bạn vẫn có thể làm cho chúng bắt đầu khi khởi động Windows và để chúng chạy trong nền. Tuy nhiên, nó liên quan đến một số mục đăng ký và một số phần mềm trong mã của bạn - việc sử dụng c api dễ dàng hơn nhiều so với .NET. Mặt khác, Microsoft đã làm điều này dễ dàng hơn nhiều bằng cách tạo ra các dịch vụ và cho phép chúng tôi đăng ký chúng với HĐH Nó đơn giản và dễ thực hiện hơn nhiều so với thực hiện thủ công.

Ví dụ về các chương trình ứng cử viên:

• Các hệ thống phải giám sát tài nguyên / ứng dụng khác và gửi báo cáo (hoạt động của người dùng, loại lưu lượng tệp cụ thể, thông báo về hành vi sai của ứng dụng)

• Các hệ thống cung cấp dịch vụ cho các ứng dụng cục bộ khác (bản dịch, chuyển đổi tệp, nhắn tin liên hệ thống)

• Phần mềm diệt virus.

Tôi nghĩ đây là những ví dụ lớn không thể dễ dàng thực hiện bằng các tác vụ theo lịch trình.

Ví dụ yêu thích của tôi về việc sử dụng dịch vụ:

1. Máy chủ - chương trình phục vụ yêu cầu từ khách hàng từ xa. Họ thường sẽ chạy như các dịch vụ để đảm bảo rằng chúng có sẵn bất kể người dùng có đăng nhập vào máy chủ hay không. Chạy như một dịch vụ cũng có nghĩa là máy chủ bắt đầu xử lý các yêu cầu ngay khi máy khởi động, không ai phải đăng nhập vào máy để khởi động chương trình sau khi máy được khởi động lại vì bất kỳ lý do nào. Một máy chủ cơ sở dữ liệu là một ví dụ tuyệt vời.
2. Xử lý nền - các chương trình chịu trách nhiệm xử lý dữ liệu từ nguồn dữ liệu và lưu trữ kết quả vào mục tiêu dữ liệu. Mục tiêu dữ liệu thường là một nguồn cho một quá trình khác, v.v. Chạy như các dịch vụ cho phép các chương trình đó chỉ cần ngồi ở đó và chờ dữ liệu đến. Nó cũng cho phép các nhà phát triển cải thiện sự mạnh mẽ của quá trình xử lý bằng cách chia quá trình thành nhiều bước bán độc lập.

Đây là cách sử dụng mẫu của khái niệm dịch vụ với mã thực (se bên dưới).

Những gì nó làm là cấu hình một bus dịch vụ tiêu thụ hàng đợi và lắng nghe các tin nhắn từ các máy chủ web và GUI khách.

Khi nhận được thông báo, miền này thực hiện logic gì, nó sẽ lưu các sự kiện vào đĩa và xuất bản các sự kiện đó cho người môi giới tin nhắn.

Hầu hết các ứng dụng lớn hơn được ghép lỏng lẻo thực hiện một số loại kiến ​​trúc "công nhân" như điều dưới đây.

Dự án Documently là một dự án mẫu mà chúng tôi đã tạo cho những người như bạn để tìm hiểu kiến ​​trúc phân tán. Bạn có thể đặt câu hỏi trực tiếp cho tôi trong dự án, hoặc phân nhánh nó và thực hiện một số tính năng để tìm hiểu và sau đó gửi yêu cầu kéo (và nhận nhận xét mã).

https://github.com/haf/Documently/blob/master/src/Documently.Domain.Service/Program.cs :

using System.Threading;
using Castle.MicroKernel.Registration;
using Castle.Windsor;
using Documently.Infrastructure;
using Documently.Infrastructure.Installers;
using MassTransit;
using Topshelf;
using log4net;
using log4net.Config;

namespace Documently.Domain.Service
{
    class Program
    {
        private static readonly ILog _Logger = LogManager.GetLogger(typeof (Program));

        private IWindsorContainer _Container;
        private IServiceBus _Bus;

        public static void Main(string[] args)
        {
            Thread.CurrentThread.Name = "Domain Service Main Thread";
            HostFactory.Run(x =>
            {
                x.Service<Program>(s =>
                {
                    s.ConstructUsing(name => new Program());
                    s.WhenStarted(p => p.Start());
                    s.WhenStopped(p => p.Stop());
                });
                x.RunAsLocalSystem();

                x.SetDescription("Handles the domain logic for the Documently Application.");
                x.SetDisplayName("Documently Domain Service");
                x.SetServiceName("Documently.Domain.Service");
            });
        }

        private void Start()
        {
            XmlConfigurator.Configure();
            _Logger.Info("setting up domain service, installing components");

            _Container = new WindsorContainer()
                .Install(
                    new RavenDbServerInstaller(),
                    new CommandHandlerInstaller(),
                    new EventStoreInstaller(),
                    new BusInstaller(Keys.DomainServiceEndpoint)
                    );

            _Container.Register(Component.For<IWindsorContainer>().Instance(_Container));
            _Bus = _Container.Resolve<IServiceBus>();

            _Logger.Info("application configured, started running");
        }

        private void Stop()
        {
            _Logger.Info("shutting down Domain Service");
            _Container.Release(_Bus);
            _Container.Dispose();
        }
    }
}

Cách đây một thời gian, nhóm của tôi đã triển khai 3 dịch vụ windows trên một ngân hàng ở Brazil, như sau:

• Giao diện giữa các hệ thống: Chúng tôi có một ứng dụng văn phòng chịu trách nhiệm đặt các giao dịch trên thị trường chứng khoán và một ứng dụng văn phòng, chịu trách nhiệm kế toán và tính phí giao dịch. Ban đầu, giao tiếp hệ thống giao tiếp được thực hiện trực tiếp trên SQL Server, nhưng quá nhiều vấn đề về khóa và duy trì đã khiến hệ thống bị ảnh hưởng bởi hiệu năng kém. Một dịch vụ đã được triển khai để kết nối với cả cơ sở dữ liệu trước và sau và thực hiện đọc / ghi đúng cách bằng cách sử dụng một loại chiến lược duy trì nào đó (thay vì viết mỗi giao dịch trên SQL Server, chúng tôi giữ dữ liệu cho một số giao dịch mở rộng, giả sử 1000 giao dịch và đã chèn một số lượng lớn, nhanh hơn 40 lần so với giải pháp ban đầu và không khóa nhiều bảng liên quan trong một thời gian dài).

• Hàng đợi tin nhắn: Cùng với giải pháp trước đó, chúng tôi đã viết một trình xử lý hàng đợi tin nhắn tùy chỉnh, vì vậy một số quy trình xử lý hàng loạt có thể chạy không đồng bộ. Điều đó đã được tích hợp với cả MSMQ và IBM-MQSeries.

• Tập trung hóa các dịch vụ kinh doanh: Chẳng hạn, một số ứng dụng người dùng cần dữ liệu chung như giá cổ phiếu, vì vậy chúng tôi đã viết một dịch vụ tùy chỉnh chịu trách nhiệm nhận "yêu cầu giá" và gửi lại thông tin về giá.

Một trong những khía cạnh khiến chúng tôi viết dịch vụ, thay vì "robot", là các dịch vụ có thể chạy như một người dùng cụ thể (như ai đó đã chỉ ra trên chuỗi này) và có thể được khởi chạy tự động khi máy khởi động.

Các dịch vụ cũng không cần máy tính để bàn hoặc dịch vụ quản lý cửa sổ để chạy. Họ có thể chạy trên nền (tốt, họ phải chạy trên nền).

Và, nếu bạn giống như một số đồng nghiệp của tôi không thích viết giao diện người dùng, dịch vụ là những thách thức lớn về công nghệ, bởi vì thông thường họ không được thất bại. Vì vậy, thật vui khi viết một dịch vụ. :)

Nếu bạn đang thiết kế một ứng dụng máy tính để bàn Windows cần chạy như người dùng chuẩn nhưng đôi khi cần thực hiện một tác vụ yêu cầu quyền quản trị viên, bạn có thể sử dụng dịch vụ.

Trình cài đặt của bạn sẽ cài đặt dịch vụ với các quyền cần thiết, ứng dụng máy tính để bàn của bạn gọi đến dịch vụ khi cần thực hiện một tác vụ với đặc quyền quản trị viên.

Có những ý nghĩa bảo mật cho phương pháp này nằm ngoài phạm vi của câu trả lời này.

Đối với các lập trình viên, lý do chính để sử dụng dịch vụ là:

• Chương trình này cần khởi động tự động trên máy Windows sau khi khởi động lại.

Bất cứ điều gì bạn viết phải tuân thủ các điều trên phải chạy như một Dịch vụ Windows.

Dịch vụ hữu ích nhất tôi đã viết, từ góc độ người dùng cuối:
* Người dùng đã in hóa đơn UGLY trên máy in ma trận điểm với trình điều khiển in RAW.
* Người dùng muốn có hóa đơn PRETTY với logo, đồ họa trơn.
* Không có quyền truy cập vào mã kế thừa.

Dịch vụ này sẽ:
* Giám sát (nhiều) thư mục máy in cho các công việc in.
* Tạo một tệp PDF của hóa đơn.
* PDF sẽ "lót" một hình ảnh hóa đơn trống đẹp
* Lớp phủ văn bản thô
* Tra cứu dữ liệu meta, dựa trên thư mục đang được sử dụng (IE: máy in đang được sử dụng)

Sau đó, siêu dữ liệu sẽ:
* Tạo PDF
* và / hoặc in PDF
* và / hoặc gửi tệp PDF đến thư mục đích cuối cùng
* và / hoặc xóa tệp PDF
* và / hoặc gửi email hóa đơn PDF cho khách hàng

Trong trường hợp này, nó xử lý các công cụ ghost-script, PLC và PDF. Nó đã hoạt động rất sạch sẽ trong nhiều năm. Bao gồm các tệp nhật ký !!!